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Abstract 

Security  requirements  for  a  task,  system  or  network  may  permit  the  selection  of  a  range  of  underlying 
services  or  security  behaviors.  When  a  range  of  services  is  available,  variant  security  is  possible.  Variant 
security  permits  the  notion  of  Quality  of  Security  Service  (QoSS)  to  be  introduced.  This  paper  describes  a 
quality  of  security  service  demonstration,  specifically  with  respect  to  costing.  We  describe  the  network  as 
having  three  modes:  normal,  impacted,  and  emergency.  For  each  of  these  modes,  the  user  is  given  three 
possible  security  levels:  low,  medium  and  high.  A  variety  of  security  services  contribute  to  the  overall 
security  of  each  task  Each  service  has  two  costs:  an  initialization  cost  and  a  run-time  cost.  The 
demonstration  illustrates  the  costs  incurred  as  network  modes  and  security  levels  are  changed.  High  level 
and  detailed  specifications  are  provided. 

Quality  of  Security  Service  (QoSS)  is  possible  when  there  is  ■variant  security ,  i.e.  mechanisms 
that  “allow  a  range  of  security  behaviors”  [3]  and  “offer  the  user  various  “degrees”,  or  strengths, 
of  security”[l].  The  base  system  security  policy  may  impose  certain  minimum  requirements  for 
security.  Assuming  that  underlying  system  mechanisms  can  provide  variant  security  according  to 
user  choices  for  security  level,  an  application  could  provide  various  degrees  of  security,  always 
complying  though  with  the  restrictions  placed  by  the  system’s  policy. 

When  an  application  /  task  is  executed,  it  may  access  various  network  resources  (e.g.  bandwidth, 
CPU,  storage).  Security  costs  are  fixed  if  there  are  no  security  selections.  Variant  security,  on  the 
other  hand,  causes  a  security  overhead  for  the  application  which  will  depend  on  the  user’s 
request.  For  each  variant  security  mechanism  we  need  information  for  the  resource  costs 
associated  with  the  specific  task.  This  way  we  are  able  to  estimate  a  cost  for  security  on  a  per- 
task,  per-resource  basis  [3]. 

A  preliminary  taxonomy  of  security  services,  as  the  groundwork  for  a  system  to  supply  security¬ 
costing  information  to  an  RMS,  is  presented  in  [1],  [2].  An  application/task  may  invoke  the  use  of 
various  security  services  (e.g.,  authenticity,  confidentiality,  integrity,  non-repudiation,  etc.).  The 
notion  of  service  area  [1]  associates  the  security  mechanism(s)  that  implement  the  service,  with  a 
topographical  component  of  the  network.  A  list  of  security  services,  mechanisms,  and  services  is 
provided  in  [1], 

A  method  for  making  the  interaction  with  a  wide  range  of  security  services  and  mechanisms 
comprehensible  and  easy  for  administrators  and  users  is  presented  in  [3]. 

A  task  is  characterized  by  a  set  of  security  requirements  that  must  be  met.  This  set  of 
requirements  can  vary  if  a  dynamic  network  security  policy  is  applied.  This  means  that  the 
network  status  or  “mode”  (e.g.  normal,  emergency,  impacted  mode)  will  influence  the  security 
restrictions  and  available  security  services  for  the  task.  We  can  predefine  a  set  of  alternate 
security  policies.  If  the  network  administrator  changes  the  network  mode  of  operation,  the 
appropriate  policy  will  be  employed,  and  the  corresponding  set  of  security  requirements  will 
apply  to  a  specific  task  [3].  Thus,  a  high-level  interface  (mode  selection)  allows  the  alternation 
between  security  policies. 

Similarly  a  user  can  specify  the  desired  degree  of  security  service,  that  is  to  be  applied  to  the 
processing  of  the  network  task.  Instead  of  presenting  to  the  user  all  combinations  of  security 
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mechanisms  and  parameters  for  the  variant  services,  we  can  offer  a  set  of  security  level  choices 
(e.g.  high,  medium,  low).  These  abstract  choices  are  translated  to  a  pre-selected  set  of  security 
mechanisms  and  settings.  This  way  we  can  map  “a  simplified  user  abstraction  of  security  to 
detailed  underlying  mechanisms,  such  that  users  can  be  presented  with  a  coherent  user-level  view 
of  available  security  options”  [3], 

The  Quality  of  Security  Service  Costing  Demonstration  illustrates  the  concepts  described  above 
and  provides  a  method  for  quantifying  costs  related  to  the  security  service.  Using  the  taxonomy 
we  identify  services  (discriminating  between  service  areas)  that  tasks  may  invoke,  and  security 
mechanisms  that  implement  them.  We  pre-defme  sets  of  security  settings,  corresponding  to 
network  modes  and  user  security  level  choices.  Costs  for  a  task  are  calculated  and  expressed  in 
terms  of  resources.  These  costs  depend  on  the  specific  task’s  security  characteristics  that  were 
selected. 

In  Appendix  A,  the  purpose  and  the  requirements  for  the  Quality  of  Security  Service  Costing 
Demonstration  are  presented. 

Various  logical  structures  are  also  introduced: 

To  describe  security  requirements  posed  from  the  network  system  for  a  specific  task,  a  Task 
Requirement  Vector  is  used  consisting  of  service  requirement  components.  Mode  Service  Matrix 
incorporates  the  idea  of  dynamic  network  and  alternate  sets  of  security  policies. 

To  describe  a  set  of  specific  security  settings  for  a  task,  we  use  a  Task  Variable  Vector. 
Availability  of  abstract  user  security  level  choices,  leads  to  the  need  for  a  set  of  Task  Variable 
Vectors,  described  by  a  Choice  Variable  Matrix.  Furthermore  the  effect  of  mode  selection  on  the 
security  settings  is  expressed  through  the  Mode  Choice  Matrix. 

The  cost  for  a  resource  during  execution  of  a  specific  task  is  specified  in  a  resource  cost 
expression.  Costs  for  all  resources  of  a  service  are  described  in  a  Service  Cost  Vector  and  costs 
for  all  services  invoked  by  a  task  are  associated  with  a  certain  Cost  Matrix. 

Additionally,  generic  functions,  which  are  necessary  for  the  demo’s  required  processing  logic,  are 
presented  in  Appendix  A. 

In  Appendix  B  the  low-level  specification  for  Quality  of  Security  Service  Costing  Demonstration 
is  presented.  Objects  and  functions,  for  implementing  Appendix’s  A  logical  structures  and 
relevant  functionality,  are  specified,  along  with  necessary  constants  and  structures  for  storing 
costing  information  for  tasks. 

It  should  be  noted  that  Appendix  B  is  an  evolving  document  (and  SecurityCosts  an  application 
under  further  development).  Future  work  will  address  among  other  issues: 

•  population  of  the  demo  with  realistic  costing  data 

•  determination  of  best  units  for  cost  measures 

•  enumeration  of  specific  security  mechanisms  with  respect  to  the  described  taxonomy 

•  costing  data  storage  issues. 
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Appendix  A:  MSHN  Security  Costing 
Demonstration  Requirements 


1  Overview 

The  MSHN  project  is  designed  to  schedule  multiple  tasks  into  an  environment  that  has  a  defined 
set  of  (finite)  resources.  In  order  for  it  to  evaluate  which  tasks  and  resources  it  can  “afford”  to  run 
concurrently  in  such  an  environment,  it  needs  to  know  how  much  of  each  resource  is  consumed  by 
each  prospective  task1.  With  respect  to  security,  the  scheduler  needs  to  know  how  much  it  will 
cost  (viz,  in  .terms  of  resources)  to  meet  the  relevant  security  requirements.  For  resources  with 
fixed  security  needs,  the  overhead  is  fixed,  and  the  scheduler  does  not  have  to  perform  any  special 
calculations.  On  the  other  hand,  for  “variant”  security2,  the  scheduler  needs  to  know  the  extent  to 
which  security  will  increase  resource  cost  (i.e.,  level  of  resource  usage)  for  a  given  “degree”  of 
security  service.  A  taxonomy  of  security  services  as  well  as  an  approach  for  specifying  the  cost  of 
security  for  general  types  of  security  services  are  discussed  in  [1] . 

The  purpose  of  the  MSHN  Security  Costing  Demonstration  is  to  implement  a  prototype  mecha¬ 
nism  for  storing,  processing  and  retrieving  security  costing  data  for  a  range  of  representative  secu¬ 
rity  services.  As  a  secondary  purpose,  the  demo  will  illustrate  the  conceptual  mapping  of  high- 
level  security  requirements  to  detailed  services  for  different  network  operational  modes  (see  [2] ). 
The  effect  of  this  mapping  in  the  demo  will  be  that  the  security  costs  returned  for  a  task  will 
change  according  to  the  network  mode  and  the  user’s  choice  of  high-level  security  requirements. 

2  Requirements 

The  demo  will  produce  the  following  items  in  pursuit  of  the  purpose  stated  in  Section  1  .  These 
items  will  be  delivered  in  the  form  of  one  or  more  technical  reports,  and  one  or  more  laboratory 
demonstrations. 

•  A  defined  generic  security  service  costing  algorithm  (see  Section  4.1.1 ),  derived  from  [1] 

•  A  defined  subset  of  security  services  for  MSHN  (derived  from  the  taxonomy  in  [1] ),  and  a  par¬ 
ticularization  of  the  security  costing  algorithm  for  each  of  those  services. 

•  A  defined  set  of  hypothetical  tasks  which  invoke  elements  of  the  security  service  subset. 

•  A  defined  set  of  abstract  user  security  choices,  as  per  [2] . 

•  A  defined  set  of  administrative  network  modes,  as  per  [3] . 

•  An  automated  mechanism  and  corresponding  user  manual  for  managing  security  costing  data. 
The  mechanism  shall  provide  the  following  capabilities: 

-Take  and  store  input  for  description  of  task  and  environmental  security  requirements. 


1.  a  task  has  a  name  and  a  fixed  application  program;  it  may  be  invoked  with  various  data  sets. 

2.  security  requirements  for  which  the  user  is  allowed  a  range  of  choices  with  respect  to  the  degree  of  security 
applied.  See  [3]  for  examples. 
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-Process  a  task  request,  returning  the  estimated  security  costing  data. 

-Support  abstract  user  security  choices  with  respect  to  variant  security  requirements. 

-Support  network  operational  mode,  returning  different  estimated  security  costing  data  for  dif¬ 
ferent  modes. 


3  Conventions 

•  Identifiers  appear  in  italics. 

•  When  it  is  being  defined,  an  identifier  is  underlined. 

•  Identifiers  for  internal  variables  begin  with  an  junderbar  (“_”). 

•  Names  for  demo  interface  functions  have  a  “demo_”  prefix,  as  well  as  underbars  between  the 
words  (e.g.,  demo_function_name),  but  are  not  italicized;  internal  demo  functions  have  a  “i_” 
prefix,  instead. 

•  A  “vector”  structure  is  a  series  of  value-holding  items;  a  “matrix”  structure  is  a  series  of  vector 
structures. 

•  “<-”  is  the  assignment  operator:  “A  <-  B”  means  that  the  value  of  B  is  assigned  to  A. 

4  Development  Task  Descriptions 

Items  identified  in  Section  2  are  described  in  further  detail  as  development  tasks  in  the  sections 
below.  There  is  a  “definitions”  task  and  an  “automated  mechanism”  task,  each  with  several  sub¬ 
tasks. 

4.1  Definitions  Task 

This  subtask  is  to  provide  definitions  and  conceptual  foundations  for  the  second  task  (Section  4.2, 
“Automated  Mechanism  Task,”  on  page  9).  The  results  of  these  subtasks  may  be  consolidated  in  a 
technical  report;  they  are  integral  to  the  development  of  the  Automated  Mechanism  Task 
(Section  4.2 ). 

4.1.1  Security  Costing  Algorithm 

The  purpose  of  this  subtask  is  to  define  a  generic  security  service  costing  algorithm,  derived  from 
[1]  .  For  the  security  costing  algorithm,  the  following  logical  structures  are  defined  (see  also, 
Figure  1  on  page  4,  and  the  Appendix): 

task  requirement  vector.  A  per-task  collection  of  service  requirement  components.  This  struc¬ 
ture  is  introduced  in  [3] .  There  is  a  system  task  requirement  vector  which  contains  network 
environment  security  requirements  common  to  all  tasks  (in  processing,  the  system  vector  may 
be  logically  appended  to  the  task’s  task  requirement  vector).  Note  that  there  are  corresponding 
system  components,  as  well  as  per-task  components  for  each  of  the  following  type  of  struc¬ 
tures. 

service  requirement  component'.  A  boolean  expression  (possibly  a  compound  of  several  bool¬ 
ean  clauses)  regarding  the  security  requirements  of  a  specific  resource  or  security  service,  and 
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containing  at  most  one  variant  security  clause.  A  security  service  is  a  high-level  type  of 
resource,  which  is  typically  made  up  of  other  resources.  Resources  that  are  not  defined  in 
terms  of  other  resources  are  termed  elemental  resources.  A  security  service  may  be  repre¬ 
sented  by  one  or  more  service  requirement  components. 

task  cost  matrix;,  contains  cost  formulae  for  the  task  in  the  form  of  a  vector  of  service  cost  vec¬ 
tors.  In  the  task  cost  matrix  there  is  a  service  cost  vector  corresponding  to  each  security  ser¬ 
vice  or  resource  defined  in  the  task  requirement  vector. 

service  cost  vector,  contains  cost  data  for  a  specific  security  service  or  resource  used  by  the 
task,  in  the  form  of  a  per  service  collection  of  resource  cost  expressions.  There  is  one  expres¬ 
sion  for  each  resource  utilized  in  effecting  the  requirements  of  that  service. 

resource  cost  {depression:  contains  a  cost  expression  for  a  given  resource.  The  value  of  this 
expression  may  be  stated  relative  to  the  variant  security  variables  in  related  service  require¬ 
ment  components,  e.g.,  a  given  cost  may  be  dependent  on  another  component’s  cost  expres¬ 
sion.  Each  expression  has  the  form:  “start-up  cost  —  streaming  cost”,  where  either  “start-up 
cost”  or  “streaming  cost”  may  be  empty,  but  (realistically),  not  both. 

task  variable  vector,  a  structure  which  is  parallel  to  the  task  requirement  vector,  where  each 
component  is  used  to  specify  a  value  for  the  variant  security  variable  found  in  the  correspond¬ 
ing  service  requirement  component. 

task  result  matrix:  a  structure  which  is  parallel  to  the  task  cost  matrix,  where  each  component 
is  used  to  specify  a  vector  of  cost  results,  one  result  for  each  resource  cost  expression  in  the 
corresponding  service  cost  vector. 


Figure  1  on  page  4  shows  the  relationships  between  these  structures  with  an  example.  In  this 
example,  some  of  the  elements  (i.e.,  those  so  marked)  represent  variant  security  requirements, 
while  others  represent  invariant  security  requirements. 
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task  result  matrix  ->  (for  user  output) 


Cost  value  for  Since  the  S1/R3  cost  expression  is  invariant, 

aS  S1/R3 

^  _  the  cost  value  for  S1/R3  is  constant. 

V  (constant) 


FIGURE  1.  Per-Task,  Per-System  Vectors,  components  and  Expressions 

To  complete  the  algorithm  to  derive  the  task’s  security  service  costs  we  need  to  define  the  process¬ 
ing  for  these  vectors,  which  is  simply  the  following.  A  user  indicates  specific  Quality  of  Security 
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Service  (QOSS)  selections  in  a  task  variable  vector  submitted  with  the  task  request.  The  demo 
plugs  these  values  into  the  corresponding  resource  cost  expressions  to  derive  specific  resource 
costs  for  a  task  result  matrix,  which  is  returned  to  the  requestor 

4.1.2  Subset  of  Security  Services 

The  purpose  of  this  subtask  is  to  define  a  subset  of  the  generic  security  services  in  [1]  that  are 
pertinent  for  MSHN  and  that  will  be  useful  in  making  this  demonstration  illustrative  of  its  overall 
purposes.  Also,  this  subtask  must  provide  a  particularization  of  the  security  costing  algorithm  for 
each  element  of  the  subset. 

The  list  of  security  service  categories  from  [1]  is  as  follows 


Table  1:  Security  Services 


IN 

NW 

ES 

TS 

Data/object  Confidentiality3 

X 

X 

X 

Data/object  Integrity3 

X 

X 

X 

Traffic  Flow  Confidentiality 

X 

X 

X 

Authenticity 

X 

X 

X 

Non-Repudiation 

X 

X 

Guarantee  of  Service 

X 

X 

X 

Availability 

X 

X 

X 

Audit  and  Intrusion  Detection 

X 

X 

Boundary  Control 

X 

a.  applies  to  protection  of  data  objects  as  well  as  various 
types  of  other  objects,  such  as  network  nodes,  subnets,  and 
devices. 


As  shown  in  Table  1  ,  services  in  each  of  these  categories  may  be  employed  for  protection  in 
intermediate  network  nodes  (IN),  network  wire  (NW),  end  systems  (ES),  with  the  exception  of 
audit  and  boundary  control,  which  effect  security  in  the  total  subnet  (TS)  and  non-repudiation, 
which  effects  only  intermediate  node  and  end  system  security. 


SUBSET 

From  discussions  with  MSHN  sponsoring  organizations  and  review  of  MSHN  planning  docu¬ 
ments  (e.g.,  [5] )  the  following  subset  of  generic  security  services  is  found  to  be  relevant  to  the 
MSHN  operational  environment: 

Data/object  Confidentiality  ES,  IN  (network  objects  are  protected) 

Data/object  Integrity  NW,  ES  (data  transmission  as  well  as  network  objects  are  protected) 
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Authenticity  NW 

Audit  and  Intrusion  Detection  TS 


EXAMPLE  PARTICULARIZATION 

This  section  provides  an  example  of  how  the  security  service  costing  algorithm  would  be  particu¬ 
larized  to  suit  one  of  the  elements  of  the  subset,  the  “data  integrity  on  the  wire”  security  service. 

•  task  requirement  vector: 

a  vector  with  three  components  is  defined. 

•  service  requirement  component: 

The  first  component  states  that  network  communications  using  subnet  Subnet_A  will  be  cryp¬ 
tographically  signed  to  provide  integrity  at  the  packet  level,  with  a  rate  of  integrity  checking 
greater  than  60%.  Such  a  range  of  checking  might  be  useful  in  transmitting  images  or  other 
streams  of  data  that  are  “averaged”  somewhat  by  the  receiver.  The  second  component  states 
that  the  symmetric  key  length  used  on  Subnet_A  will  be  in  a  certain  range.  The  third  compo¬ 
nent  states  that  the  user  is  authorized  to  use  the  subnet,  and  is  an  invariant  expression.  The  first 
two  components  describe  requirements  for  use  of  the  “data  integrity  on  the  wire”  security  ser¬ 
vice. 

-(S la)  \/ p  :packets,  s:subnet((send(p,j)  &  s  =  Subnet_A)  ->  i_packet_integrity_rate(s)  >=  .60) 

-(Sib)  V p  :packets,  $:subnet((send(p,s)  &s  =  Subnet_A)  ->  56  <=  i_key_length(s)  <=  128) 

-(S2)  V p  :packets,  j:subnet((sendfp,j)  &  s  =  Subnet_A)  ->  authorized_access(user_id(p),  s)) 


•  task  cost  matrix: 

a  vector  with  two  components  is  defined. 

•  service  cost  vector: 

(Cl)  contains  cost  data  for  use  of  the  “data  integrity  on  the  wire"  (SI)  security  service.  This 
vector  has  three  components,  use  of  the  cpu  (Cl/Rl),  memory  (C1/R2),  and  bandwidth  (Cl/ 
R3)  resources.  (Each  expression  has  the  form:  start-up  cost  —  streaming  cost.) 

-(Cl/Rl)  5000  processor  clocks  +  (10  clocks  x  i_key_length(Subnet_A))  --  40  Processor  clocks  per  packet  x 
i_packet_integrity_rate(Subnet_A) 

-(C1/R2)  (6144  +  i_key_length(Subnet_A))  bytes  —  (5120  +  i_key_length(Subnet_A))  bytes 
-(C1/R3)  0—8  bytes  per  packet  x  i_packet_integrity_rate(Subnet_A) 

-(C2)  empty  (S2  is  constant,  so  no  expression  is  required  here). 

•  task  variable  vector: 

a  vector  with  three  componentsis  defined. 

-(Via)  i_packet_integrity_rate(Subnet_A)  =  .8 
-(Vlb)  i_key_length(Subnet_A)  =  128 

-(V2)  empty  (S2  is  constant,  so  no  expression  is  required  here). 

•  task  result  matrix: 

a  matrix  with  two  vectors  is  defined,  to  contain  security  costs  for  the  two  defined  services. 
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•  service  result  vector: 

-(Ol/Rl)  6280  processor  clocks  —  32  Processor  clocks  per  packet 
-(01/R2)  6016  bytes  memory  —  5248  bytes  memory 
-(01/R3)  0  —6.4  bytes  per  packet,  bandwith  overhead 

-(02)  empty 
-(03)  empty 

4.1.3  Hypothetical  Tasks 

The  purpose  of  this  subtask  is  to  define  a  set  of  hypothetical  tasks  which  invoke  elements  of  the 
security  service  subset. 

example 

An  example  of  an  application  or  user  task  which  would  utilize  the  packet  integrity  service  is  a 
simple  network  file  transfer  program,  like  ftp. 

4.1.4  Abstract  User  Security  Choices 

The  purpose  of  this  subtask  is  to  define  a  set  of  abstract  user  security  choices,  as  per  [2] ,  for  users 
to  symbolically  select  predefined  task  variable  vectors.  To  represent  this  choice,  we  introduce  the 
following  structure: 

choice  variable  matrix:  a  structure  which  maps  user  security  choices  to  task  variable  vectors. 
Mechanisms  for  managing  the  choice  variable  matrix  are  provided  in  Section  4.2  . 

example 

For  this  example,  we  will  use  the  example  abstract  user  security  choices  from  [2] : 
user  security  choice ::=  (high  I  medium  I  low) 

A  set  of  mappings  is  defined  for  these  user  security  choices  and  the  variables  in  component  V 1  of 
the  example  task  variable  vector. 

HIGH  ->  (Via)  i_packet_integrity_rate(Subnet_A)  =  1;  (Vlb)  i_key_length(Subnet_A)  =128 
;  (V2)  undefined 

MEDIUM  ->  (Via)  i_packet_integrity_rate(Subnet_A)  =  .8;  (Vlb  i_key_length(Subnet_A)  =  96 
;  (V2)  undefined 

LOW  ->  (Via)  i_packet_integrity_rate(Subnet_A)  =  .6;  (Vlb)  i_key_length(Subnet_A)  =  56 
;  (V2)  undefined 
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A  corresponding  choice  variable  matrix  for  these  mappings  is  shown  in  Table  2  : 


Table  2:  Choice  Variable  Matrix 


User  Security  Choice 

Bfljigi 

ilill 

.6 

.8 

.6 

®Si 

56 

96 

128 

siisi 

undefined 

undefined 

undefined 

4.1.5  Network  Mode  Choices 

The  purpose  of  this  subtask  is  to  define  a  set  of  administrator-selectable  network  modes,  as  per  [2] 
[3] .  The  different  modes  determine  different  security  characteristics  for  the  tasks  and  the  network 
system.  To  represent  the  semantics  of  these  modes,  we  introduce  the  following  structures: 

mode  service  matrix:  a  structure  which  maps  networks  modes  to  task  requirement  vectors. 

mode  choice  matrix:  a  structure  which  maps  network  modes  to  choice  variable  matrixes. 
Mechanisms  for  managing  the  these  matrixes  are  provided  in  Section  4.2  . 

example :  modes 

For  this  example,  we  will  use  the  example  network  mode  choices  from  [2]  [3] : 
network  mode::=  (normal  I  impacted  I  emergency) 

example:  modes  mapped  to  task  requirement  vectors 

The  alternate  mappings  from  these  modes  to  different  task  requirement  vectors  forms  a  mode  ser¬ 
vice  matrix : 

-normal  ->  (Sla)  V p  :packets,s:subnet((send(p,s)  &  s  =  Subnet_A)  ->  packet  integrity  rate(Subnet_A)  >=  .60); 
(Sib)  56  <=  i_key_length(Subnet_A)  <=  128;  (S2)  authorized_access(user_id(p),  Subnet_A) 

-impacted  ->  (Sla)  Vj 0  :packets,s:subnet((send(p,s)  &  s  =  Subnet_A)  -> 

.20  <=  packet  integrity  rate(Subnet_A)  <=.60); 

(Sib)  i_key_length(Subnet_A)  =  56;  (S2)  authorized_access(user_id(p),  Subnet_A) 

-emergency  ->  (Sla)  Vp  :packets,s:subnet((send(p,s)  &  s  =  Subnet_A)  ->  packet  integrity  rate(Subnet_A)  =  1); 
(Sib)  i_key_length(Subnet_A)  =  128;  (S2)  authorized_access(user_id(p),  Subnet_A) 

example:  modes  mapped  to  user  security  choices 

The  alternate  mappings  for  user  security  choices,  based  on  network  modes  are  shown  in  Table  3  . 
Logically,  this  forms  a  3-component  vector  of  choice  variable  matrixes,  called  a  mode  choice 
matrix. 
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Table  3:  mode  choice  matrix 


User  Security  Choice 

'?3§§§|- 

jp$j$ 

’  U;':"  . 

normal 

jg§jj 

.6 

.8 

1 

111111 

56 

96 

128 

j§0§ 

undefined 

undefined 

undefined 

<D 

impacted 

jjjjj 

.2 

.4 

.6 

O 

% 

mi 

56 

56 

56 

undefined 

undefined 

undefined 

emergency 

g|f§j 

1 

1 

1 

g||§ 

128 

128 

128 

111 

undefined 

undefined 

undefined 

modes  not  mapped  to  task  costs 

On  the  other  hand,  variable  task  costs  are  built  into  the  cost  expressions,  so  mappings  external  to 
those  expressions  are  not  required. 

4.2  Automated  Mechanism  Task 

The  purpose  of  this  task  is  to  produce  an  automated  mechanism  and  user  manual  for  managing 
security  costing  data.  Development  of  the  mechanism  consists  of  the  following  subtasks.  Func¬ 
tions  are  presented  in  a  generic  syntax  to  show  the  required  processing  logic.  The  demo  need  not 
preserve  the  variable  syntax  or  specific  interfaces  show  here. 

4.2.1  Specification  of  internal  state 

The  purpose  of  this  subtask  is  to  consolidate  in  one  place  the  logic  for  the  internal  state  of  the 
automated  mechanism,  such  that  the  specification  for  the  rest  of  the  subtasks  in  this  task  can  spec¬ 
ify  their  “effects”  (viz,  changes)  relative  to  that  state.  These  logical  constructs  represent  global 
variables  in  the  demonstration  mechanism.  First  we  define  an  indexing  mechanism: 

task/svstem  designator,  indicates  a  specific  task  or  the  network  system.  Typically,  as  below,  a 
vector  may  have  components  for  each  task,  as  well  as  one  for  the  network  system. 

We  introduce  a  system  constant  of  type  task/system  designator  to  represent  the  network  sys¬ 
tem:  SYSTEM. 

Global  Variables 

current  operational  mode :  a  network  mode ,  by  default  set  to  “normal.”  This  indicates  the 
mode  that  is  currently  in  effect  for  the  network  system  as  a  whole. 
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mode  services(tas,k/svsttm  designator):  the  mode  service  matrix  for  the  system  or  designated 
task. 


current  service  vccfc>r(task/svstem  designator):  a  task  requirement  vector,  which  is  currently 
in  effect  for  the  system  or  designated  task.  Changes  to  _current  operational  mode  change  the 
value  of  this  variable. 

mode  choices  (task/ system  designator):  the  mode  choice  matrix  for  the  system  or  designated 
task. 

current  choice  matrixj task/svstem  designator):  a  choice  variable  matrix,  which  is  currently 
in  effect  for  the  system  or  designated  task.  Changes  to  jcurrent  operational  mode  change  the 
value  of  this  variable. 

current  cost  matrixftask/svstem  designator):  the  task  cost  matrix  for  the  system  or  designated 
task. 

4.2.2  Task  and  environment  setup 

The  purpose  of  this  subtask  is  to  create  functions  for  the  automated  mechanism  to  take  and  store 
administrator  input  for  specification  of  security  attributes  of  tasks  and  the  network  environment. 

demo_set_task_services 

This  function  establishes/updates  the  security  services  and  requirements  for  the  system  or  a  task. 

Input 

TSD:  task/system  designator  -  indicates  the  task  (or  the  system)  for  which  to  modify  requirements 
TSV:  task  requirement  vector  -  new  security  requirements 

Output 

none 

Processing 

none 

Effects 

update  jcurrent  service  vector  for  the  system  or  task  to  the  value  of  TSV: 
jcurrent  service  vectoriJSD)  <-  TSV 

demo_set_task_costs 

This  function  establishes/updates  the  cost  formulas  for  the  system  or  a  task. 

Input 

TSD:  task/system  designator  -  indicates  the  task  (or  the  system)  for  which  to  modify  requirements 
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TCM:  task  cost  matrix  -  new  security  costing  information 

Output 

none 

Processing 

none 

Effects 

update  _current  cost  matrix  for  the  system  or  task  to  the  value  of  TCM: 

_current  cost  matrix^ TSD)  <-  TSV 

4.2.3  Process  task  request 

The  purpose  of  this  subtask  is  to  create  functions  for  the  automated  mechanism  to  take  user  input 
for  and  process  a  task  request.  Processing  will  result  in  the  return  of  estimated  security  costing 
data  to  the  user. 

demo_task_request 

This  function  issues  a  request  to  the  demo  for  a  task’s  security  costing  information.  The  security 
costing  information  is  an  estimate  of  the  cost  to  access  the  variant  security  mechanisms  associated 
with  running  the  task. 

Input 

TSD:  task/system  designator  -  indicates  the  task  for  which  to  return  information 

TVV:  task  variable  vector  -  specifies  the  values  of  task-specific  variables  for  execution  of  this  task 

STW:  task  variable  vector  -  specifies  the  values  of  system-specific  variables  for  execution  of  this 
task 

Output 

TRM:  task  result  matrix  -  cost  values  for  the  task 
STRM:  task  result  matrix  -  cost  values  for  the  system. 

Output  format  shall  provide  intuitive  correspondence  to  the  input  (e.g.,  same  nomenclature). 

Processing 

Use  i_task_request  with  the  inputs  to  obtain  the  output: 
output  <-  i_task_request(TSD,  TVV,  STW) 

Effects 

none 

i_t a sk_r eque s t 

This  function  calculates  the  costs  of  a  task  request 
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Input 

TSD:  task/system  designator  -  indicates  the  task  for  which  to  return  information 

TVV:  task  variable  vector  -  specifies  the  values  of  task-specific  variables  for  execution  of  this  task 

STW:  task  variable  vector  -  specifies  the  values  of  system-specific  variables  for  execution  of  this 
task 

Output 

TRM:  task  result  matrix  -  cost  values  for  the  task 
STRM:  task  result  matrix  -  cost  values  for  the  system. 

Processing 

The  security  choices  indicated  in  the  task  variable  vectors  (TRM  and  STRM)  are  plugged  into 
_current  cost  matrix^ TSD)  and  _current  cost  matrix{ SYSTEM),  respectively,  to  arrive  at  estimated 
costs. 

Effects 

none 

4.2.4  Support  abstract  user  security  choices 

The  purpose  of  this  subtask  is  to  create  functions  for  the  automated  mechanism  to  take  and  store 
administrative  input  that  maps  abstract  user  security  choices  (Section  4.1.4  )  to  the  exact  security 
choices  found  in  the  task  variable  vector  for  the  system  or  a  task. 

Additionally,  this  subtask  modifies  the  demo_task_request  interface  (Section  3.2.2)  to  take  an 
abstract  user  security  choice.  demo_task_request  processing  is  modified  to  obtain  exact  security 
choices  from  the  user  security  choice. 

demo_map_user_choices 

This  function  initializes  or  modifies  the  detailed  security  choices  associated  with  each  defined 
abstract  user  security  choice. 

Input 

TSD:  task/system  designator  -  indicates  the  task  (or  the  system)  for  which  to  modify  security 
choices 

CVM:  choice  variable  matrix  -  a  set  of  mapping  statements,  correlating  each  abstract  user  security 
choice  to  a  task  variable  vector. 

Output 

none 

Processing 

none 

Effects 

The  system  or  task’s  _current  choice  matrix  is  overwritten  with  the  input,  i.e.: 
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_current  choice  matrix( TSD)  <-  CVM. 

Note:  optionally,  this  function  could  also  take  a  user  security  choice,  and  work  on  one  choice  of 
the  task’s  current  choice  matrix  at  a  time. 


demo_task_request_2 

This  function  issues  a  request  to  the  demo  for  a  task's  security  costing  information. 

Input 

TSD:  task/system  designator  -  indicates  the  task  for  which  to  return  information 

USC:  user  security  choice  -  the  user’s  choice  of  security  for  the  invocation  of  this  function. 

Output 

TRM:  task  result  matrix  -  cost  values  for  the  task 
STRM:  task  result  matrix  -  cost  values  for  the  system 

Processing 

Use  the  abstract  user  security  choice  to  obtain  a  task  variable  vector  for  the  task  and  the  system 
from  the  ^current  choice  matrix.  Internal  variables  _I_TVV  and  _I_STVV  of  type  task  variable  vec¬ 
tor  are  introduced  for  illustration: 

_I_TW  <-  ( _current  choice  matm(TSD)).USC 
_I_STW  <-  (_current  choice  matrixes YSTEM)).USC 

Use  i_task_request  with  the  resulting  task  variable  vectors  to  obtain  the  output. 

output  <-  i_task_request(TSD,  _I_TVV,  _I_STW) 

Effects 

none 


4.2.5  Support  network  operational  mode 

The  purpose  of  this  subtask  is  to  create  functions  for  the  automated  mechanism  to  take  and  store 
administrative  input  to  (1)  set  the  _current  operational  mode  and  associated  internal  state,  (2)  set 
the  per-task  and  system  _mode  services  matrixes  (viz,  alternate  task  requirement  vectors  for  the 
different  modes),  and  (3)  set  the  per-task  and  system  _mode  choices  (viz,  alternate  abstract  user 
security  mappings  relative  to  those  vectors/modes). 

demo_set_network_mode 

This  function  sets  the  value  of  the  network  operational  mode. 

Input 

MODE:  network  mode  -  new  network  operational  mode,  as  per  Section  4.1.5 

Output 

none 
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Processing 

none 

Effects 

jcurrent  operational  mode  is  set  to  value  of  MODE. 

For  each  ENTRY  of  type  task/system  designator  (viz,  all  tasks  and  the  system  entry),  _current  ser¬ 
vice  vector  and  jcurrent  choice  matrix  are  set  to  the  component  indicated  by  MODE  in  the  corre¬ 
sponding  jnode  services  and  jnode  choices  matrixes: 

jcurrent  service  vector(ENTRY)  <-  jnode  ^ ervzce^ (ENTRY )  .MODE 
jcurrent  choice  matrix{ ENTRY)  <-  jnode  c/z0Zces(ENTRY )  .MODE 


demo_s e t_mode_s ervic e s 

This  function  initializes  or  modifies  the  jnode  services  matrix  for  a  task  or  the  system.  This  func¬ 
tion  replaces  demo_set_task_services. 

Input 

TSD:  task/system  designator  -  indicates  the  task  (or  the  system)  for  which  to 

msm:  mode  service  matrix  -  a  set  of  alternate  task  requirement  vectors,  each  mapped  to  a  different 
network  mode,  per  Section  4.1.5  . 

Output 

none 

Processing 

none 

Effects 

System/Task's  jnode  services  matrix  is  modified  according  to  input: 
jnode  5erv/ce5(TSD)  <-  MSM 

Note:  again,  this  function  could  just  as  well  include  a  mode  parameter,  and  effect  only  one  mode 
of  jnode  services,  per  task 

demo_set_mode_maps 

This  function  initializes  or  modifies  the  jnode  choices  matrix  for  a  task  or  the  system.  This  func¬ 
tion  replaces  demo_map_user_choices 

Input 

TSD:  task/system  designator  -  indicates  the  task  (or  the  system)  for  which  to  set  alternate  user 
choices. 

MCM:  mode  choice  matrix  -  a  set  of  choice  variable  matrixes,  each  mapped  to  a  different  network 
mode,  per  Table  3  . 
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Output 


none 

Processing 

none 

Effects 

System/Task’s  _mode  choices  matrix  is  modified  according  to  the  input: 
_mode  choices(TSD)  <-  MCM 


5  ERRATA 

Interoperability  with  MSHN  and/or  the  MSHN  demos  might  be  considered. 

The  RMS  default  values  for  task  variables  (e.g.,  for  use  when  the  user  has  specified  a  range  rather 
than  a  specific  value  for  a  variant  security  variable)  are  not  represented  (see  [4] ).  These  values 
could  be  considered  to  be  in  special  additional  _current  choice  matrixes  for  each  task,  but  the 
details  need  to  be  worked  out. 

It  is  not  clear  that  _mode  services  or  any  task  requirement  vector  or  mode  service  matrix  is  actu¬ 
ally  needed  to  implement  this  demo.  However  these  structures  are  included  in  the  demo  descrip¬ 
tion  as  essential  to  understanding  the  service  vector  abstraction. 
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Appendix:  BNF  for  Structures  and  Variables 


The  structure  of  the  demo  structure  types  and  variables  is  represented  here  in  a  Backus-Naur 
form.  In  this  form,  “+”  indicates,  “one  or  more”  of  the  item  enclosed  in  preceding  parentheses, 
and  that  some  suitable  separator  is  logically  inserted  between  multiple  items  (e.g., 


system 

_current  operational  mode  ::=  mode 


system  and  per- task 

_mode  services  ::=  mode  service  matrix 

mode  service  matrix  ::=  (mode,  task  requirement  vector)+ 

_current  service  vector  ::=  task  requirement  vector 

task  requirement  vector  ::=  (service  requirement  component)+ 

service  requirement  component  ::=  boolean  expression  of  requirements 

_current  cost  matrix  ::=  task  cost  matrix 
task  cost  matrix  ::=  (service  cost  vector)+ 
service  cost  vector  ::=  (resource  cost  expression)+ 

_mode  choices  ::=  mode  choice  matrix 

mode  choice  matrix  ::=  (mode,  choice  variable  matrix)+ 

_current  choice  matrix  ::=  choice  variable  matrix 

choice  variable  matrix  ::=  (user  security  choice,  task  variable  matrix)+ 

task  variable  matrix  ::=  (variable  specification^ 

user  security  choice  :  :=  string 
network  mode  ::=  string 

Output /Return 

task  result  matrix  ::=  (service  result  vector)+ 
service  result  vector  ::=  (cost  value)+ 


Further  derivation  of  and  syntax  for  these  non-terminal  symbols  are  left  to  the  reader:  “boolean 
expression  of  requirements,”  “resource  cost  expression,”  “variable  specification,”  “string,”  and 
“cost  value  ” 
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A.  INTRODUCTION 


The  Quality  of  Security  Service  Costing  Demonstration  for  the  MSHN  Project  illustrates 
a  method  for  quantifying  costs  related  to  the  security  service.  This  document  is  the  low- 
level  specification  for  the  demonstration.  Objects  that  implement  the  needed  logical 
structures,  functions  that  provide  the  required  functionality,  along  with  structures  for  cost 
data  are  described  here. 

Pre-defined  costing  information  for  tasks  and  the  security  services  they  invoke,  is 
necessary.  This  information  can  be  stored  in  a  database  or  in  a  set  of  files.  Aspects  of 
both  approaches  are  covered  here.  We  have  selected  to  store  the  costing  data  in  the  layout 
that  is  closest  to  the  needed  logical  structures  for  the  costing  application.  This  may  allow 
some  redundancy  on  the  stored  data,  but  facilitates  significantly  the  application 
processing  on  files  or  data  base  tables. 

Note  1:  In  the  current  software  version  costing  info  data  are  not  stored  in  disk.  Array 
structures  similar  to  the  disk  structures  are  employed,  with  hardwired  values  for  a  couple 
of  pre-defined  tasks,  and  the  ability  to  input  data  for  new  tasks. 

Note  2: 

In  all  material  following  only  absolutely  necessary  elements  (fields  of  structures)  are 
displayed.  Additional  fields  (like  version  number,  text  descriptions,  etc...  can  be  added 
later) 

The  layout  of  the  rest  of  the  document  is: 

B.  Application  Functionality 

C.  Application  Constants 

D.  File  Structures 

E.  Specification  of  entities 

F.  Future  Refinements 

G.  Arrays 

H.  Data  Base  Structures 


B.  APPLICATION  FUNCTIONALITY 

B.l  Conventions 

The  abbreviations  below  are  widely  used  throughout  the  document: 
MSM:  Mode  Service  Matrix 
TRV :  Task  Requirement  V  ector 
MCM:  Mode  Choice  Matrix 
CVM:  Choice  Variable  Matrix 
T V V :  T ask  Variable  V ector 
CM:  Cost  Matrix 

File  structures  are  referred  to  as  below: 
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(FileI)  “Task.dat” 

(File2)  “MSMtoTRV.dat” 

(FILE3.1  -FILE3.X)  “TRV***.dat” 

(File4)  “MCMtoCVM  .dat” 

(File5)  “CVMtoTVV.dat” 

(File6.1  -  File6.Y)  “TVV***. dat” 

(FILE7.1  -FILE7.Z)  “CM***. dat” 

Data  base  structures  are  referred  to  as  below: 

(DB1)  Task 

(DB2)  MSM_to_TRV 

(DB3)  Requirement_Components 

(DB4)  Task_Requirement_Vector 

(DB5)  MCM_to_CVM 

(DB6)  CVM_to_TVV 

(DB7)  Variable_Values 

(DB8)  Task_Variable_Vector 

(DB9)  CM_to_Service_Costs 

(DB10)  Cost_Matrix 

Application  functions  using  Files  or  DB  structures  have  the  comment  below,  next  to 

their  name: 

//FileAccess  {ODBC} 

A  DB  structure  field  is  referred  to  as  Structurelndex.FieldName  e.g.  Al.Cost 

A  record’s  specific  field  is  referred  to  as  Record[StructureIndex.FieldName] 


B.2  Description  of  Operation 

The  costing  demonstration  was  initially  perceived  to  work  on  a  “one-time  request”  basis. 
This  means  that  the  user  requests  one  specific  costing  service  each  time,  the  request  is 
processed,  and  for  subsequent  requests  the  cycle  repeats  exactly  the  same: 

>  User  inputs  info 

■  task 

■  security  choice  level  for  this  task 

■  network  mode  for  this  task  (actually  Administrator  inputs  this) 

>  Application  processes 

■  “loads”  task  relevant  info  from  storage  structures 

■  selects  current  TRV,  TVV  and  CM  according  to  mode  and  choice  selections 

■  plugs  TVV  values  and  to  cost  formulas  pointed  by  CM 

■  fills  results  in  CM 

>  Application  displays  results  in  layout  selected  by  user 

With  this  approach  only  one  task’s  info  is  cached  into  program’s  memory,  and  it’s 
deleted  each  time  a  request  for  a  different  task  is  issued,  so  that  the  new  info  is  loaded 
from  the  storage  structures. 
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Variations  on  this  concept  of  operation  can  exist: 

For  example  the  user  could  select  only  the  specific  task  and  then  the  application  could 
calculate  and  display  security  costs  for  all  possible  combinations  of  choice  and  mode. 


B.3  Interfaces 

4  Initialization  of  files  (Administrative  Interface) 

Functionality  will  be  supplied  to  create  new  files,  to  add  entries  to  existing  files,  but  not 
to  modify  existing  info  at  this  stage. 

This  is  because  modification  of  “high-level”  structures  can  be  a  complicated  matter. 
Modification  of  a  task’s  MSM  for  example  could  mean  various  things: 

-  change  1,  2,  or  all  3  TRVs  the  MSM  is  pointing  to, 
where  change  a  TRV  could  mean 

-  make  MSM  point  to  a  different  but  existing  TRV 

-  make  MSM  point  to  a  different  TRV,  and  create  TRV 

-  let  MSM  point  to  the  same  TRV  and  change  the  ReqComponents  of  the  TRV 

Initialization  of  files  should  be  executed  at  least  once  (or  implicitly  invoked  if  files  do  not 
exist). 

■4  Input  (User  Interface) 

User  selects  from  existing  lists  the  task  id,  network  mode,  and  security  choice  level  for 
the  costing  request. 

Only  an  administrator  can  determine  the  network  mode. 

-An  extra  function  should  exist  for  data  input,  if  they  are  needed  for  cost  calculations. 

-An  extra  function  later  for  user  defining  specific  component  variable  values  (not  abstract 
security  choices) 

4  Costing  Request  (User  Interface) 

User  issues  a  costing  request.  This  translates  to: 

-ensuring  that  task  relevant  info  exist  in  program  memory  (retrieve  from  storage 
structures  if  needed) 

-selecting  TRV,  TVV,  CM  for  current  mode,  choice 
-plugging  values  from  TVV  to  compVariablef] 

-calculating  costs,  by  calling  appropriate  cost  formulas 

4  Display  Cost  Results  (User  Interface) 

This  could  be  a  separate  request  or  invoked  along  with  the  costing  request,  when  user 
wishes  other  than  the  default  display  option. 

The  user  can  select  to  view 
-all  costs  for  all  services 
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-costs  for  all  services  for  a  specific  resource 

-costs  for  all  services  for  a  specific  resource  and  a  specific  cost  type 

-all  costs  for  one  service 

-costs  for  a  specific  resource  of  a  service 

-costs  for  a  specific  resource  and  a  specific  cost  type  of  a  service 

4  Display  Various  Info  (User  Interface) 

User  selects  to  display  info  for 
-current  CM  formulas 
-current  TRV  requirement  components 
-current  TVV  variable  values 

B.4  Cost  Formulas  and  Component  Variables 

An  explanation  for  the  cost  formulas  and  component  variable  values  as  visualized  in  the 
current  approach  should  be  given: 

Storage  of  cost  formulas  (and  generally  mathematical  expressions)  in  files  or  data  base 
tables  could  not  be  conceived  in  a  straightforward  and  efficient  way.  It  was  thus  chosen 
to  store  instead  indexes  to  cost  formulas  that  should  be  used  for  a  specific  task’s  service 
resource  cost.  The  various  cost  formulas  are  program  functions.  They  are  called  through  a 
function  (costDispatcherQ),  which  calls  the  appropriate  cost  formula  based  on  the  index 
(stored  /  loaded  in  memory). 

Let’s  assume  that  we  have  the  “data  integrity  on  the  wire”  security  service  of  a  task. 

The  cost  Formula  for  the  start  cost  of  the  resource  CPU  for  this  service  depends  on  the 
symmetric  key  length  (this  is  the  component  variable  used)  and  is  something  like: 

(5000  +  10  x  key_length)  clocks. 

When  TWs  are  stored  or  retrieved,  what  is  actually  stored/retrieved  is  a  pair  of 
(COMPONENT_VARIABLE  constant,  specific  Value_RHS), 
for  example  (C V_KE Y JLEN GTH,  56). 

In  our  application  frame  we  do  not  define  a  variable  name  for  each  component  variable 
(e.g.  key_length)  and  then  associate  straight  the  name  with  its  value.  Instead  we  define  an 
array 

real  compVariable[total_number_of_COMPONENT_VARIABLES] 

The  number  of  elements  is  equal  to  the  number  of  all  different  component  variables  used 
in  the  various  TRVs  (and  TVVs). 

We  refer  to  a  specific  component  variable  as: 

compV ariable[COMPONENT_V ARI ABLE  constant] 

So  each  variable  always  corresponds  to  the  same  array  position,  e.g.  when  we  refer  in  our 
application  to  the  component  variable  key_length,  we  use 
compVariable[CV_KEY_LENGTH] 

So,  the  cost  formula  above  will  be  expressed  in  our  program  as: 
real  costFormula5Q  { 
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real  x; 

result  =  5000+10 *comp  Variable  [* CV_KEY_LENGTHJ ; 
return  x; 

} 

When  a  specific  TVV  has  been  selected  and  pairs  like 
CV_KEY_LENGTH,  56 

have  been  “loaded”,  then  with  function  Task.VariableVector::plugValues,  we  do 
something  like: 

comp  Variable  [CV_KEY_LENGTHJ  =  56; 

For  the  current  task,  not  all  component  variables  participate  in  its  cost  formulas  (that  is, 
not  all  components  get  a  value  from  the  specific  TVV).  So  for  each  update  of  Task 
Variable  Vector  and  before  plugging  new  values  to  the  compVariablef],  we  should  first 
null  the  array: 

for  i=0  to  number of '  COMPONENT  VARIABLES 
comp  Variable  [i]  =NULL 

A  function  like  the  one  below  will  be  used,  to  invoke  the  appropriate  cost  formula, 
according  to  cost  function  id  fields  in  info  loaded  from  (File7.X)  “CM***.dat”  or 
(DB10)  Cost_Matrix: 

costDispatcher (function  Jd,  *result) 

{  case  functioned  of 

5: 

* result  =  costFormula5Q; 

} 

As  already  mentioned,  these  formulas  are  expressed  in  terms  of  compVariablef]  array 
elements. 


C.  APPLICA  TION  CONSTANTS 


TASK  constants 


#define 

T  FTP 

0 

#define 

T  WEB  BROWSER 

1 

#define 

T  UNDEFINED  1 

2 

#define 

T  UNDEFINED  2 

3 

#define 

T  UNDEFINED  3 

4 

//String  description  of  tasks 

const  CString  s_Task[5]  =  {  "FTP",  "SECURE  WEB  BROWSER", 

"UNDEFINED",  "UNDEFINED",  "UNDEFINED",}; 


SERVICE  constants 

#defme  S_CONFIDENTIALITY_NW  0 

#define  S_CONFIDENTIALITY_ES  1 

#define  S_INTEGRITY_NW  2 
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#define  SJNTEGRITYJBS  3 

#define  S_AUTHENTICITY_ES  4 

#define  S_AUDIT_TS  5 

//String  description  of  security  services 

const  CString  s_Service[6]  =  { "CONFIDENTIALITYJSfetworkWire", 

"CONFIDENTIALITY JEndSystem",  "INTEGRITY_NetworkWire" , 
"INTEGRITY_EndSystem" ,  "AUTHENTICITY JEndSystem", 

"  AUDIT_T  otalSubnet" } ; 


SECURITYCHOICE  constants 
#defme  CH_LOW  0 

#defme.  CH_MEDIUM  1 

#defme  CH_HIGH  2 

//String  description  of  security  level  choices 
const  CString  s_Choice[3]  =  {"LOW",  "MEDIUM",  "HIGH"}; 

NETWORK_MODE  constants 
#define  M_NORMAL  0 

#defme  MJMPACTED  1 

#defme  M_EMERGENCY  2 

//String  description  of  network  modes  of  operation 

const  CString  s_Mode[3]  =  {"NORMAL",  "IMPACTED",  "EMERGENCY"}; 

COMPONENTS ARI ABLE  constants 
#define  CVINTEGRRATE  0 

#define  CV_SYM_KEY_LENGTH  1 

#defme  CV_ACCESS  2 

#define  CVALGORITHM  3 

#defme  CV_PUB_KEY_LENGTH  4 

//String  description  of  component  variables 


const  CString  s_Comp Variable [5]  =  { "PACKET JNTEGRITYJRATE", 
"SYMMETRIC_KEY_LENGTH",  "CLIENT_AUTHORIZED_ACCESS", 
"SYMMETRIC_ALGORITHM",  "SERVER_AUTHENTICATION_KEY_LENGTH" } ; 

RESOURCE  constants 

#define  R_CPU  0 

#define  R_MEMORY  1 

#define  RJBANDWIDTH  2 

//String  description  of  resources 

const  CString  s_Resource[3]  =  {"CPU_A",  "MEMORY",  "BANDWIDTH"}; 

//Each  resource's  string  description  of  start-up  cost  unit 
const  CString  s_StartUnit[3]  =  {"  clocks", "  bytes", "  bytes"}; 

//Each  resource's  string  description  of  streaming  cost  unit 

const  CString  s_StreamUnit[3]  =  {"  clocks/packet", "  bytes", "  bytes/packet"}; 

//String  description  of  formulas 
const  CString  s_Formula[22]  = 
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{"0", 

"5000  +  10  x  SYMMETRIC JCEY_LENGTH", 

"40  x  P  ACKET_INTEGRITY_RATE" , 

"6144  +  SYMMETRIC_KEY_LENGTH", 

"5120  +  SYMMETRIC_KEY_LENGTH", 

"8  x  PACKET_INTEGRITY_RATE", 

"200  x  CLIENT_AUTHORIZED_ACCESS  +  1000", 

"2048  x  CLIENT_AUTHORIZED_ACCESS  +  67584", 

"100", 

" S YMMETRIC_ALGORITHM  x  (30000  +  100  x  SYMMETRIC_KEY_LENGTH)", 
"SYMMETRIC_ALGORITHM  x  (512  +  8  x  SYMMETRIC_KEY_LENGTH)", 

"  S  YMMETRIC_ALGORITHM  x  (8500  +  100  x  SYMMETRIC_KEY_LENGTH)", 
"SYMMETRIC_ALGORITHM  x  (6500  +  100  x  SYMMETRIC_KEY_LENGTH)", 
"SYMMETRIC_ALGORITHM  x  2", 

"SYMMETRIC_ALGORITHM  x  (5000  +  10  x  SYMMETRIC_KEY_LENGTH)", 
"SYMMETRIC_ALGORITHM  x  (40  x  P  ACKET_INTEGRITY_RATE)" , 

"  S  YMMETRIC_ALGORITHM  x  (6144  +  S  YMMETRIC_KE  Y_LENGTH)" , 
"SYMMETRIC_ALGORITHM  x  (5120  +  SYMMETRIC_KEY_LENGTH)", 

"  S  YMMETRIC_ALGORITHM  x  (8  x  PACKET_INTEGRITY_RATE)", 

"200  x  CLIENT_AUTHORIZED_ACCESS  +  4000  +  10  x 
SERVER_AUTHENTICATION_KEY_LENGTH", 

"2048  x  CLIENT_AUTHORIZED_ACCESS  +  77584  +  5  x 
SERVER_AUTHENTICATION_KEY_LENGTH", 

"612  +  SERVER_AUTHENTICATION_KEY_LENGTH" }; 


Application  constants 

const  int  MAX_TASK  =  5;  //Maximum  number  of  tasks  in  demo 

const  int  MAXJREQCOMP  =  5;  //Maximum  number  of  Requirement 

//Components  in  a  task 

const  int  MAX_SERV  =  3;  //Maximum  number  of  Services  in  a  task 


We  use  these  values,  in  order  to  keep  arrays  with  costing  info  (that  need  initializing...)  to 
an  easily  manageable  size  for  this  version. 


D.  FILE  STRUCTURES 


(FileI)  “Task.dat” 

Structure  containing  for  each  task  corresponding  indexes  to  Mode-Service,  Mode-Choice 
and  Cost  Matrices. 

Number  of  entries  equals  number  of  defined  tasks. 

Corresponding  DB  Structure:  (DB1)  Task 


Field 

Description 

Example 

ID 

integer 

0  (T_FTP) 
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_ a  TASK  constant  -  indicates  task’s  id _ 

Mode-Service  integer 

indicates  id  of  corresponding  Mode-Service 
matrix 

Mode-Choice  integer 

indicates  id  of  corresponding  Mode-Choice 
matrix 

Cost  integer 

indicates  id  of  corresponding  Cost  matrix 
NrComponents  integer 

indicates  number  of  requirement 
components  (=number  of  component 
variables)  of  task 
NrServices  integer 

indicates  number  of  security  services 
invoked  by  task 

NOTE:  for  a  different  costing  algorithm  another  field  could  be  added,  for  an  alternative 
cost  matrix. 


(File2)  “MSMtoTRV.dat” 

(MODE-SERVICE  MATRIX  to  TASK  REQUIREMENT  VECTOR) 

Structure  containing  for  each  Mode-Service  Matrix  indexes  to  Task  Requirement 
Vectors  according  to  network  mode. 

Number  of  entries  equals  number  of  defined  tasks. 

Corresponding  DB  Structure:  (DB2)  MSM_TO_TRV 


Field _ Description^ _ Example 

ID  integer 

_ indicates  Mode-Service  Matrix’s  id _ 

Normal_TRV  integer 

indicates  id  of  Task  Requirement  Vector  for 
normal  mode 

Impacted_TRV  integer 

indicates  id  of  Task  Requirement  Vector  for 
impacted  mode 

Emergency_TRV  integer 

indicates  id  of  Task  Requirement  Vector  for 
emergency  mode 

(FILE3.1  -  FILE3.X)  “TRV***.dat” 

A  set  of  files  with  filename  TRV***.dat,  where  ***  is  the  id  of  TRV: 

TRVl.dat, ...,  TRVx.dat 

Number  of  files  equals  number  of  all  possible  Task  Requirement  Vectors 

(x  =  number_of_Tasks  *  number_of  _modes) 
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Number  of  entries  in  each  file  equals  nrCompi  =  number  of  requirement  components  of 
TRY  i  (which  is  a  matter  of  definition) 


Corresponding  DB  Structure:  specific  (DB4)  Task_Requirement_Vector 
Because  if  this  set  of  files,  a  file  corresponding  to  (DB3)  Requirement_Components  is 
not  needed. 


nrComps  is  the  first  info  in  file.  The  rest  of  the  entries  are  as  follows: 


Field 

Description 

Example 

ID 

integer 

indicates  Requirement 
Component’s  id 

VariableJLHS 

integer 

a  COMPONENTS ARI ABLE 
constant  -  indicates  variable 
clause  of  component 

1 

(CV_SYM_KEY_LENGTH) 

Min_Range_V  alue 

float 
a  number 

.6 

Max_Range_V  alue 

float 
a  number 

.8 

NOTE:  Additional  fields  e.g.  for  instantiated  values  can  be  included 
(File4)  “MCMtoCVM  .dat” 

(MODE-CHOICE  MATRIX  to  CHOICE  VARIABLE  MATRIX) 

Structure  containing  for  each  Mode-Choice  Matrix  indexes  to  Choice  Variable  Matrixes 
according  to  network  mode. 

Number  of  entries  equals  number  of  defined  tasks. 

Corresponding  DB  Structure:  (DB5)  MCM_TO_CVM 


Field 

Description 

Example 

ID 

integer 

indicates  Mode-Choice  Matrix’s  id 

Normal_CVM 

integer 

indicates  id  of  Choice- Variable  Matrix 
for  normal  mode 

Impacted_CVM 

integer 

indicates  id  of  Choice- Variable  Matrix 
for  impacted  mode 

Emergency_CVM 

integer 

indicates  id  of  Choice- Variable  Matrix 
for  emergency  mode 
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(File5)  “CVMtoTW.dat” 

(CHOICE- VARIABLE  MATRIX  to  TASK  VARIABLE  VECTOR) 

Structure  containing  for  each  Choice  Variable  Matrix  indexes  to  Task  Variable  Vectors 
according  to  security  level  choice. 

Number  of  entries  equals  number_of_tasks  *  number_of_modes. 


Corresponding  DB  Structure:  (DB6)  CVM  _TO_TVV 


Field 

Description 

Example 

ID 

integer 

indicates  Choice- Variable  Matrix’s  id 

Low_TVV 

integer 

indicates  id  of  Task  Variable  Vector  for  low  level 
security  choice 

Medium_TVV 

integer 

indicates  id  of  Task  Variable  Vector  for  medium 
level  security  choice 

High_TVV 

integer 

indicates  id  of  Task  Variable  Vector  for  high 
level  security  choice 

(File6.1  -  FILE6.Y)  “TW***.dat” 

A  set  of  files  with  filename  TVV***.dat,  where  ***  is  the  id  of  TVV: 

TVVl.dat, ...,  TVVy.dat 

Number  of  files  equals  number  of  all  possible  Task  Variable  Vectors 

(y  =  number_of_Tasks  *  number_of  jtnodes  *  number_of_security_choices) 

Number  of  entries  equals  to  nrCompi  =  number  of  requirement  components  of 
corresponding  Task’s  TRV  i  (which  is  a  matter  of  definition) 

Corresponding  DB  Structure:  specific  (DB8)  TASK_VARIABLE_VECTOR 

Because  if  this  set  of  files,  a  file  corresponding  to  (DB7)  VariableJValues  is  not 

needed. 

nrCompj  is  the  first  info  in  file.  The  rest  of  the  entries  are  as  follows: 


Field 

Description 

Example 

Variable_LHS 

integer 

a  COMPONENTS ARI  ABLE 
constant  -  indicates  variable  clause 
of  component 

1  (CV_KEY_LENGTH) 

Min_V  alue_RHS 

float 

number  indicating  minimum  of 
acceptable  value  range 

.6 

MaxValueRHS 

float 

number  indicating  maximum  of 
acceptable  value  range 

.7 
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(FILE7.1  -  FILE7.Z)  “CM***.dat” 

A  set  of  files  with  filename  CM***.dat,  where  ***  is  the  id  of  CM: 

CMl.dat, CMz.dat 

Number  of  files  equals  to  number  of  defined  Tasks 

Number  of  entries  equals  nrServiceSj  =  number  of  services  of  Task  i  (which  is  a  matter  of 
definition) 

Corresponding  DB  Structure:  specific  (DB10)  Cost_Matrix 

Because  if  this  set  of  files,  a  file  corresponding  to  (DB9)  CM_to_Service_Costs  is  not 
needed. 


nrServiceSj  is  the  first  info  in  file.  The  rest  of  the  entries  are  as  follows: 

Field  Description  Example 

Service  integer  3  (S_INTEGRITY_NW) 

a  SERVICE  constant  -  indicates 
id  of  service 

CPU_Start_Cost  integer 

indicates  id  of  function  used  to 

calculate  start  cost  for  CPU. _ 

CPU_Stream_Cost  integer 

indicates  id  of  function  used  to 

calculate  streaming  cost  for  CPU.  _ 

memory_Start_Cost  integer 

indicates  id  of  function  used  to 
calculate  start  cost  for  memory. 
memory_Stream_Cost  integer 

indicates  id  of  function  used  to 
calculate  streaming  cost  for 
memory. 

bandwidth_Start_Cost  integer 

indicates  id  of  function  used  to 
calculate  start  cost  for  bandwidth. 
bandwidth_Stream_Cost  integer 

indicates  id  of  function  used  to 
calculate  streaming  cost  for 
bandwidth. 
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E.  SPECIFIC  A  TION  OF  ENTITIES 


E.l  The  Application  Frame 

The  SecurityCosts  application  is  implemented  in  Microsoft  Visual  C++  Version  6.0, 
using  the  Microsoft  Foundation  Class  (MFC)  Library. 

We  could  summarize  the  functionality  of  the  application  frame  as  follows: 
there  is  a  loop  running  continuously  and  checking  the  event  messages.  While  the  message 
is  not  the  “quit”  message,  the  application  frame  sends  the  events  to  the  objects  that  have 
the  appropriate  event  handlers.  A  simplified  example  of  the  respective  code  is: 

getEvent(eventlD) ; 
while  (eventID  !=  QUIT) 

{ 

switch(eventlD) 

{ 

case  MENUJU  SER_SELECT_TASK : 

CSecurityCostsDoc.OnUserTask() 
case  MENU_ADMINI  STRAT  OR_NET  WORK_MODE: 

CSecurityCostsDoc.OnAdministratorNetworkModeO 
case  MENU_USER_SECURITY_LEVEL: 

CSecurityCostsDoc.OnUserSecurityLevel() 
case  MENU_USER_PROCESS_COSTS : 

CSecurityCostsDoc.OnUserProcessCostsO 
case  MENU_ADMINISTRATOR_SETUP_TASK: 

CSecurityCostsDoc.OnAdministratorSetupTaskO 
case  MENU_USER_SECURITY_REQUIREMENTS_INFO: 

CSecurityCostsView.OnUserDisplayTRVsInfo() 
case  MENU_U  SER_SECURITY_CHOICES_INF  O : 

CSecurityCostsView.OnUserDisplayTVVsInfo() 
case  MENU_USER_COST_F  ORMUL  AS : 

CSecurityCostsView.OnUserDisplayCostInfo() 
case  MENU_USER_DISPL  AY_COST_RESULTS : 

CSecurityCostsView.OnUserDisplayCostResultsO 

} 

getEvent(eventlD); 


} 

The  CSecurityCostsDoc  object  handles  events  generated  by  the  user’s  menu  requests  for: 
-selection  of  task  (respective  handler:  OnUserTask() ) 

-selection  of  network  mode  (respective  handler:  OnAdministratorNetworkModeO ) 
-selection  of  security  level  (respective  handler:  OnUserSecurityLevel() ) 

-processing  of  costs  (respective  handler:  OnUserProcessCostsO ) 

-set-up  of  a  new  task  (respective  handler:  OnAdministratorSetupTask() ) 
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The  CSecurityCostsView  object  handles  events  generated  by  the  user’s  menu  requests  for 
display  of: 

-TRVs  info  (respective  handler:  OnUserDisplayTRVsInfo() ) 

-TVVs  info  (respective  handler:  OnUserDisplayTVVsInfo() ) 

-cost  formulas  (respective  handler:  OnUserDisplayCostlnfoO ) 

-cost  results  (respective  handler:  OnUserDisplayCostResultsQ ) 


E.2  Object  entities 

The  CSecurityCostsView  object  handling  display  of  costing  info  and  results  is  not 
described  here,  since  it  only  involves  the  way  that  data  are  presented  (which  may 
change). 

Interface  dialog  boxes  are  also  not  described  in  this  document  for  similar  reasons. 

For  the  objects  specified  in  this  paragraph,  description  of  constructors  and  destructors  is 
included  only  when  they  perform  a  special  action. 

Get  functions  for  private  members  of  objects  are  not  described  in  this  document,  since 
their  effect  is  trivial. 

Objects  and  functions  generated  automatically  by  or  related  specifically  to  the  MFC 
framework  are  also  not  described. 


CSecurityCostsDoc 

y,‘: ’,u. ■Y/r/.'TA'y/Ar/,  ■y.-yr.’AVsV/SA  YAYAy.  ysYr%'V.cyjzy/.:y*Y/*  A AArr/AZA'A zayyl  y~  >: ~ yayaay:-/.' yA:yAy<AA£Y+YAiYYS/~7AY/A: yjzYAS/A?/AYAS//z'/A7/AV&/Ar/Ar/Ar//v/£YA,yA'A;:y. \ yyy/..  A. 

CSecurityCostsDoc::  CSecurityCostsDoc  //definition  of  entity 

{//MEMBERS 

Task  testTask; 

int  curTaskID;  //a  TASK  constant 
int  curModelD;  //a  NETWORK_MODE  constant 
int  curChoicelD;  //a  SECURITY_CHOICE  constant 
Task*  curTask; 

//ModeServiceMtrx*  curMSM; 

//TaskReq  Vector*  curTRV; 

ModeChoiceMtrx*  curMCM; 

Choice VariableMtrx*  curCVM; 

TaskVariableVector*  curTVV; 

CostMtrx*  curCM; 

float  compVariable[20]; 

//FUNCTIONS 

OnUserTask(); 

OnAdministratorNetworkMode(); 

OnUserSecurityLevel(); 

OnUserProcessCosts(); 

OnAdministratorSetupT  ask() 

selectTaskID(); 

selectModeID(); 
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selectChoicelDO ; 
selectCurrentMatricesV  ectors(); 
costFormulaO(); 
costFormulal(); 

costFormula21(); 

costDispatcher(int  formula,  float*  result); 
plugValues(); 
nullCompVariableArrayO; 
calculateCosts(); 

} 

CSecurityCostsDoc::OnUserTaskO 

-calls  selectTaskIDQ 

-calls  testTask.  initialize (curTaskID) 

-calls  selectCurrentMatrices  Vectors  Q 


CSecurityCostsDoc::  OnAdministratorNetworkModeQ 

-calls  selectModelDQ 

-calls  selectCurrentMatrices  Vector sQ 


CSecurityCostsDoc::OnUserSecurityLevelO 

-calls  selectChoicelDO 

-calls  selectCurrentMatrices  Vectors Q 


CSecurityCostsDoc::OnUserProcessCosts() 

-calls  calculateCostsQ 


CSecurityCostsDoc::  OnAdministratorSetupTaskO 

In  current  version  this  function  displays  various  dialog  boxes,  inputs  task  info  from  user 
and  stores  it  in  arrays 

( dbTaskfJO ;  dbMSMtoTR V[][],  dbTRV[][][],  dbMCMtoCVMfJfJ,  dbCVMtoTW[J[J, 
dbTW [][][] ,  dbCM[][][J) 

Later  task  info  will  be  stored  in  files/DB  tables 


CSecurityCostsDoc::selectTaskIDO 

-calls  appropriate  interface  for  input  of  task  id  value 
-sets  curTaskID  to  input  value 


CSecurityCostsDoc:  :selectModeIDO 

-calls  appropriate  interface  for  input  of  mode  id  value 
-sets  curModelD  to  input  value 


CSecurityCostsDoc::selectChoiceID() 

-calls  appropriate  interface  for  input  of  choice  id  value 
-sets  curChoicelD  to  input  value 
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CSecurityCostsDoc::selectCurrentMatricesVectorsO 

-sets  curTask  =  &testTask 

-sets  curMCM  -  curTask->getTaskMCMQ; 

-sets  curCVM  —  curMCM->getModeCVM(curModeID); 

-sets  curTW  =  curCVM->getChoiceTW(curChoiceID); 

-sets  curCM  =  curTask->getTaskCMQ; 

CSecurityCostsDoc: :  calculateCostsO 

-calls  nullCompVariableArrayQ 
-calls  plugValuesQ 
-for  all  services  of  curCM 
-for  all  resources 

-calls  costDispatcher  with  id  of  startupFunction  and  the  result  put  in  startupCost 
-calls  costDispatcher  with  id  of  streamFunction  and  the  result  put  in  streamCost 

CSecurityCostsDoc::costDispatcher(int  formula,  float*  result) 

-based  on  a 
case  formula  of 
XXX: 

_ -calls  appropriate  costFormulaXXXQ  and  sets  *result  to  return  value _ 

SET  of  CSecurityCostsDoc:  :costFormulaXXX() 

-calculates  and  return  specific  cost  expression,  using  values  of  certain  elements  of 
compVariable[]. _ 

CSecurityCostsDoc: :  costFormulaOQ _ 

-returns  value  0. _ 

CSecurityCostsDoc:  :costFormula21Q 

-if  compVariable[CV_ACCESS]  equals  0 
-returns  value  0. 

else 

-returns  value  of  expression  612  +  compVariable[CV_PUB_KEY_LENGTH] 

CSecurityCostsDoc::nullCompVariableArrayO 

-  for  i=0  to  total  number _of_COMPONENT_VARIABLES 
-sets  compVariable[i]  to  0 

CSecurityCostsDoc:  :plugValues  0 

-comp Variable []  elements  whose  corresponding  variable  is  included  in  curTW,  get  the 
corresponding  value  with  the  loop: 
for  i=0  to  curTW->getTW_SIZEQ 

compVariable[curTW->  get  Var Entry  (i)->getld() ]  = 

curTW->getVarEntry(i).getMinValueQ 
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Task 


Task::Task 

{//MEMBERS 

int 

int 

int 

ModeServiceMtrx 

ModeChoiceMtrx 

CostMtrx* 

//FUNCTIONS 


id; 

nrComponents; 

nrServices; 

taskMSM; 

taskMCM; 

taskCM; 


//definition  of  entity 


} 


initialize(int  inpl); 
setld(int  input); 
setNrComponents(int  inpl) 
setNrServices(int  inpl) 
setModeServiceMatrix(int  input); 
setModeChoiceMatrix(int  input); 
setCostMatrix(int  input); 

dbGetEntryTask(int*  l_nrComp,  int*  l_nrServ,  int*  l_msm,  int*  l_mcm, 

int*  l_cm); 


dbGetSpecificCM(int  input,  *par); 


Task::initialize(int  inpl) 

-defines  local  variables 

int  locNr Components,  locNrServices 
int  mtrxMS,  mtrxMC,  mtrxCM 
-calls  setld(inpl) 

-calls  dbGetEntryTask(&locNrComponents,  &locNrServices,  &mtrxMS,  &mtrxMC, 

&mtrxCM) 

-calls  setNrComponentsflocNrComponents) 

-calls  setNrServices(locNrServices) 

-calls  setModeServiceMatrix(mtrxMS) 

-calls  setModeChoiceMatrix(mtrxMC) 

-calls  setCostMatrix(mtrxCM) 


Task::setld(int  input) 

-sets  id  to  input 


Task::setNrComponents(int  inpl) 

-sets  nrComponents  to  inpl 


Task::setNrServices(int  inpl) 

-sets  nrServices  to  inpl 
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Task:  :setModeServiceMatrix(int  input) _ 

-calls  taskMSM.setld(input) 

-calls  taskMSM.  setTR  Vs(nrComponents) 

Task:  :setModeChoiceMatrix(int  input) _ 

-calls  taskMCM.setld(input) 

-calls  taskMCM.setCVMs (nr Components) 

Task::setCostMatrix(int  input) _ 

-creates  dynamically  a  new  CostMtrx  with  nrServices  services 
-assigns  it  to  taskCM 
-calls  taskCM->setId(input) 

-calls  taskCM->setServicesQ _ 

Task::dbGetEntryTask(int*  InrComp,  int*  l_nrServ,  int*  l  msm, 

int*  Ijncm,  int*  l_cm)  //FileAccess 

FILE  case 
(FileI)  “Task.dat” 

DB  case 

-selects  record  recX in  (DB1)  Task  for  which  Al.ID  =  id 
-sets  *l_msm  =  recXfAl  .Mode-Service] 

-sets  *l_mcm  =  recXfAl. Mode-Choice] 

-sets  *l_cm  =  recXfAl. Cost] 

-sets  *l_nrComp  =  recXfAl .NrComponents] 

-sets  *l_nrServ  =  recXfAl. NrServices] _ 

NOTE:  In  current  version  this  function  accesses  elements  of  array  dbTaskfJf] 

Task::dbGetSpecificCM(int  input,  *par) _ //FileAccess 

FILE  case 

-gets  specific  (File7.1  -  File7.Z)  “CM***.daf ’  filename  by  appending  to 
“CM”+string(input)+  dat” 

(e.g.  for  input  =  2,  filename  is  “CM2.dat”) 

-puts  info  for  filename  in  par 

DB  case 

-invokes  DB  operation  for  generation  of  (DB10)  Cost_Matrix,  from  (DB9) 
CM_TO_Service_Costs  with  A9.  CM=id 
-puts  info  for  specific  structure  addressing  in  par 

NOTE:  In  current  version  this  function  performs  no  action 
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ModeServiceMtrx 

ModeServiceMtrx::  ModeServiceMtrx  //definition  of  entity 

{//MEMBERS 

int  id;  //id  number  of  MSM 

TaskReq Vector*  modeTRV[3];  //array  of  pointers  to  TRVs  for  each  mode 

//FUNCTIONS 

~ModeServiceMtrx()  //destructor 

setld(input); 

setTRVs(int  nrReqComp); 
setModeTRV (int  idTRV,  int  index,  int  nrEntries); 
dbGetEntryMSMtoTRV(int*  l_normID,  int*  limpID,  int*  l_emID); 
dbGetSpecificTRV(int  input,  *par); 

} 

ModeServiceMtrx::  -ModeServiceMtrxQ _ 

-for  i=0  to  3 

-frees  memory  reserved  by  modeTRVfi] 


ModeServiceMtrx:  :setld(input) 

-sets  id  to  input 


ModeServiceMtrx:  :setTRVs(int  nrReqComp) 

-defines  local  variables 

intnormTRV,  impTRV,  emTRV 

-calls  dbGetEntryMSMtoTR V(&normTRV,  &impTRV,  &emTRV) 
-calls  setModeTRV(normTRV,  M_NORMAL, nrReqComp) 

-calls  setModeTRV (impTRV,  M_IMPACTED,  nrReqComp) 

-calls  setModeTRV(emTRV,  M_EMERGENCY,  nrReqComp) 


ModeServiceMtrx:  :setModeTRV(int  idTRV,  int  index,  int  nrEntries) 

-calls  dbGetSpecificTRV(idTRV) 

-creates  dynamically  a  new  TaskReqVector  with  nrEntries  requirement  components 
-assigns  it  to  modeTRV [index] 

-calls  modeTR  V [index]. setId(idTR  V) 

-calls  modeTR  V [index ].  setRequirementComponentsQ 


ModeServiceMtrx:  :dbGetEntryMSMtoTRV(int*  l_normID,  int*  l  impID, 

int*  I_emID)  //FileAccess  ( ODBQ ) 

FILE  case 

(File2)  “MSMtoTRV.dat” _ 

DB  case 

-selects  record  recX  in  (DB2)  MSM_to_TRV  for  which  A2.ID  =  id 
-sets  *l_normID  =  r e cX [A  1. Normal _TRV] 
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-sets  *l_impID  =  recXfAI.  Impacted _TRVJ 
-sets  *l_emID  =  recX[Al.  Emergency _TRV] 


NOTE:  In  current  version  this  function  accesses  elements  of  array  dbMSMtoTRV[][] 

TaskReqVector::dbGetSpecificTRV(int  input,  *par)  //FileAccess  (ODBC) 

FILE  case 

-gets  specific  (File3.1  -File3.X)  “TRV***.dat”  filename  by  appending  to 
“TRV”+string(input)+  “.dat” 

(e.g.  for  input  =  30,  filename  is  “TRV30.dat”) 

-puts  info  for  filename  in  par 


DB  case 

-invokes  DB  operation  for  generation  of  (DB4)  Task_Requirement_Vector,  from 
(DB3)  Requirement_Components  with  A3.  TRV=id 
-somehow  puts  info  for  specific  structure  addressing  in  par 


NOTE:  In  current  version  this  function  performs  no  action 


TaskReq  Vector 


•7; % r/y. yy./s;ysr/<ayjr.y/.%:r,t. ~i zy* 


TaskReqVector::TaskReqVector  //definition  of  entity 

{//MEMBERS 

int  id;  //id  number  of  TRV 

const  int  TRV_SIZE;  //number  of  components  in  req_comp[] 

ReqComponent**  req_comp;  //a  pointer  to  an  array  of  TRV_SIZE 

//pointers  to  ReqComponent  components 

//FUNCTIONS 

TaskReqVector  (int  size);  //constructor 

-TaskReq  Vector  ();  //destructor 

setld(int  input); 
setRequirementComponents(); 

dbGetNextEntryTRV(input,  int*  idReqComp,  int*  idCompVar, 

float*  minVal,  float*  maxVal) 

} 

TaskReqVector: : TaskReqVector  (int  size) 


-sets  TRV_SIZE to  size 
-for  i=0  to  TRVJSIZE 

-dynamically  creates  a  new  ReqComponent 
-assigns  it  to  req_comp[i] 
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TaskReqVector::~TaskReqVector  0 

-for  i=0  to  TRVJIZE 

-frees  memory  reserved  by  req_comp[i] 


TaskReqVector::setId(int  input) 

-sets  id  to  input 


TaskReqVector::setRequirementComponentsO 

-defines  local  variables 

int  reqcomp_id,  compvar  id 
int  compvarjnin,  compvarjnax 
-for  i=0  to  TRVJIZE 

-calls  dbGetNextEntryTRV(i,  &reqcomp_id,  &compvar_id,  &compvar jnin, 

&compvar_max) 

-calls  req_comp[i]->setld(reqcomp_id) 

-calls  req_comp[i ]->setVariable(compvar_id) 

-calls  req_comp[i]->set  Expression(compvar_min,  compvarjnax) 


TaskReqVector::dbGetNextEntryTRV(input,  int*  idReqComp,  int*  idCompVar, 

float*  minVal,  float*  maxVal) 

//FileAccess  (ODBC) 

FILE  case 

(input  needed  for  keeping  track  of  last  file  position)  (FILE3.X)  “TRV***.dat” 


DB  case 

(input  needed  for  keeping  track  of  last  record) 

-selects  next  record  recX  in  structure  (DB4)  TaskJRequirement_Vector 
-sets  *idReqComp  =  recX[A4.ID] 

-sets  *idCompVar  =  recX[A4.  Value_LHS] 

-sets  *minVal  =  recX[A4.  Min_Range_Value] 

-sets  *maxVal  =  recX[A4.Max_Range_Value] 


NOTE:  In  current  version  this  function  accesses  elements  of  array  dbTRV[][][] 


ReqComponent 

ReqComponent:  :ReqComponent  //definition  of  entity 

{//MEMBERS 
int  id; 

int  compjvariable; 

float  minvalue; 
float  max_value; 

//FUNCTIONS 


//id  number  of  requirement  component 
//id  of  component  variable 
//involved  in  the  requirement  component 
//minimum  acceptable  value  for  variable 
//maximum  acceptable  value  for  variable 
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setld(int  input); 
setVariable(int  input); 
setExpression(inputl,  input2, ...); 

} 

ReqComponent::setId(int  input) 

-set  id  to  input 


ReqComponent: :  setV  ariable(int  input) 

-sets  compvariable  to  input 


ReqComponent:  :setExpression(float  inputl,  float  input2) 

-sets  min_value,  max  value  to  inputl,  input 2  respectively 


ModeChoiceMtrx 

ry,'-/.  ~ %r. ycy. r/.rxr/.TK iweKr. rysr/.:. x~y  vc-/.jrMr,xr/s. y^/jzr/c,y. -y/yy cv. „ y^y/y/rz, 

ModeChoiceMtrx:  :ModeChoiceMtrx  //definition  of  entity 

{//MEMBERS 

int  id; 

Choice  VariableMtrx  modeCVM[3]; 

//FUNCTIONS 

setld(int  input); 

setCVMs(int  nrCompVar); 

setModeCVM(int  idCVM,  int  index,  int  nrEntries); 

dbGetEntryMCMtoCVM(int*  normlD,  int*  impID,  int*  emID); 


ModeChoiceMtrx:  :setld(int  input) 

-sets  id  to  input 


ModeChoiceMtrx:  :setCVMs(int  nrCompVar) _ 

-defines  local  variables 

int  normCVM,  impCVM,  emergCVM 
-calls  dbGetEntryMCMtoCVMf  &normCVM,  &impCVM,  &emergCVM) 
-calls  setModeCVM(normCVM ,  M_NORMAL,  nrCompVar) 

-calls  setModeCVM  (impCVM ,  M_IMP ACTED,  nrCompVar) 

-calls  setModeCVM  (emergCVM,  MEMERGENCY,  nrCompVar) 


ModeChoiceMtrx: :setModeCVM(int  idCVM,  int  index,  int  nrEntries) 

-calls  modeCVMfindex ]. setld(idCVM) 

-calls  modeCVMfindex J.  setTWs  (nr Entries) 


ModeChoiceMtrx: :dbGetEntryMCMtoCVM(int*  normlD,  int*  impID,  int*  emID) 

//FileAccess  (ODBC) 

FILE  case 
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(File4)  “MCMtoCVM  .dat” 


DB  case 

-selects  record  recX  in  (DB5)  MCM_TO_CVM  for  which  A5.1D  =  input 
-sets  *normID  =  recX[A5. Normal _CVM] 

-sets  *impID  =  recX[A5.Impacted_CVM] 

-sets  *emID  =  recX[A5. Emergency _CVMJ 

NOTE:  In  current  version  this  function  accesses  elements  of  array  dbMCMtoCVM[ ][] 


Choice  VariableMtrx 

ChoiceVariableMtrx::ChoiceVariabIeMtrx  //definition  of  entity 

{//MEMBERS 

int  id; 

int  nrCompVariables; 

TaskVariable Vector*  choiceTVV[3]; 

//FUNCTIONS 

-Choice  V  ariableMtrx(); 
setld(int  input); 
setTVVs(int  nrVar); 
setChoiceTVV(int  inputl,  int  input2); 

dbGetEntryCVMtoTVV(int  input,  int*  pari,  int*  par2,  int*  par3); 
dbGetSpecificTVV(int  input,  *par); 

} 

Choice  VariableMtrx::  ~  Choice  VariableMtrxO 
-for  i=0  to  3 

-frees  memory  reserved  by  choiceTWfiJ 

ChoiceVariableMtrx::setId(int  input) 

-sets  id  to  input 

Choice  VariableMtrx:  :setTWs(int  nrVar) 

-defines  local  variables 

int  lowTW,  medTW,  highTW 

-calls  dbGetEntry C VMtoTV V (&lo wTVV,  &medTVV,  &highTVV) 

-calls  setChoiceTW(lowTW ,  CH_LOW,  nrVar) 

-calls  setChoiceTW(medTW ,  CH  MEDIUM,  nrVar ) 

-calls  setChoiceTWfhighTW ,  CHJUGH,  nrVar) _ 

ChoiceVariableMtrx::setChoiceTW(int  idTW,  int  index,  int  nrEntries) 

-calls  dbGetSpecificTW(idTW) ; 

-creates  dynamically  a  new  TaskVariableVector  with  nrEntries  component  variables 
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NOTE:  In  current  version  this  function  accesses  elements  of  array  dbCVMtoTWf] [] 


ChoiceVariableMtrx::  dbGetSpecificTW(int  input,  *par)  //FileAccess  (ODBC 
FILE  case 

-gets  specific  (File6.1  -  File6.Y)  “TVV***.dat”  filename  by  appending  to 
“TVV”+string(input)+  “.dat” 

(e.g.  for  input  =  45,  filename  is  “TVV45.dat”) 

-puts  info  for  filename  in  par 

DB  case 

-invokes  DB  operation  for  generation  of  (DB8)  Task_Variable_Vector,  from  (DB7) 

Variable_Values  with  A  7.  TW=id 

-puts  info  for  specific  structure  addressing  in  par 

NOTE:  In  current  version  this  function  performs  no  action 


T  askV  ariable  V  ector 

yy.y.::y,:„y, % :?/y~/yyyyyr/y:yyL yy.y.yy.y,-  •/.:  vyy.'t.ysr/ss/s'y. -r/yy.  y.r. y.  ysrzr. yjr-yy  yyj;yr/^r/yr/y7/^<cy/jr/^/jrr/^vyyy^/^  r/y^A. 

TaskVariableVector::TaskVariableVector  //definition  of  entity 

{//MEMBERS 

int  id; 

const  int  TVV_SIZE;  //number  of  components  in  var_entry[] 

VariableValue**  var_entry;  //a  pointer  to  an  array  of  TVV_SIZE 

//pointers  to  VariableValue  components 

//FUNCTIONS 

TaskVariableVector(int  size) 

~T  askV  ariableV  ector() 
setld(int  input) 


Low  Level  Specification  of  QoSS  Costing  Demonstration  for  MSHN  0.3 


26 


} 


setVariables() 

dbGetNextEntryTVV(input,  int*  idTVV,  float*  minV,  float*  maxV) 


TaskVariable  Vector:  :TaskVariableVector(int  size) 

-sets  TWJSIZE  to  size 
-for  i=0  to  TWJSIZE 

-dynamically  creates  a  new  VariableValue 
-assigns  it  to  var_entry[i] 


TaskVariableV  ector :  :~T  askV  ariableV  ectorO 

-for  i=0  to  TWJIZE 

-frees  memory  reserved  by  var_entry[i] 


TaskVariableVector:  :setld(int  input) 

-set  id  to  input 


TaskVariableVector:  :setVariablesO  //FileAccess  (ODBC) 

-defines  local  variables 
int  varjd 

float  minRHS,  maxRHS 
-for  i=0  to  TW_SIZE 

-calls  dbGetNextEntryTW(i,  &var_id,  &minRHS,  &maxRHS) 

-calls  var_entry[i]->setld(var_id) 

-calls  var_entry[i]->setMinValue  (minRHS) 

-calls  var_entry[i]->setMaxValue  ( maxRHS ) 


TaskVariableVector:  :dbGetNextEntryTVV(input,  int*  idTW,  float*  minV, 

_ float*  maxV) _ //FileAccess  (ODBC) 

FILE  case 

(input  needed  for  keeping  track  of  last  file  position)  (File6.Y)  “TW***.dat” 


DB  case 

(input  needed  for  keeping  track  of  last  record) 

-selects  next  record  recX  in  structure  (DB8)  Task_Variable_Vector 
-sets  *idTW  =  recX[A8.  Variable_LHS] 

-sets  *minV  =  recX[A8.Min_Value_RHS] 

-sets  *maxV  —  recX[A8.Max_Value_RHSJ 


NOTE:  In  current  version  this  function  accesses  elements  of  array  dbTW[][][] 


VariableValue 


VariableValue::VariableValue  //definition  of  entity 

{//MEMBERS 
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int  id; 
float  min_value; 
float  max_value; 
//FUNCTIONS 

setld(int  input); 
setMinV  alue(input); 
setMaxV  alue(input) ; 


VariableValue::setId(int  input) 

-set  id  to  input 


Variable  V  alue: :  setMinV  alue(inpu  t) 

-sets  min_value  to  input 


V  ariableV  alue: :  setMaxValue(input) 

-sets  max_value  to  input 


CostMtrx 

CostMtrx::CostMtrx  //definition  of  entity 

{//MEMBERS 

int  id; 

const  int  CM  SIZE;  //number  of  services  in  serv[] 

Service*  *  serv[] ;  //a  pointer  to  an  array  of  CM_SIZE 

//pointers  to  Service  components 

//FUNCTIONS 

setld(int  input); 

setServices(); 

calculateCosts(); 

displayResultsO; 

display  Results(int  resource  1); 

displayResults(int  resource  1,  int  cost_type); 

dbGetNextEntryCM(int  inpl,  int*  servID,  int*  costl,  int*  cost2); 

} 

CostMtrx::  CostMtrx  (int  size) _ 

-sets  CM_SIZE  to  size 
-for  i=0  to  CMJSIZE 

-dynamically  creates  a  new  Service 
-assigns  it  to  servfi] 


CostMtrx:  :~CostMtrx  0 

-for  i=0  to  CM_SIZE 

-frees  memory  reserved  by  serv[i] 
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CostMtrx::setId(int  input) 

-sets  id  to  input 

CostMtrx::setServicesQ _ //FileAccess  (ODBC) 

-defines  local  variables 
int  servjd 
int  start_cost[3 ] 
int  stream  cost [3 ], 

-for  i=0  to  CMJSIZE 

-calls  dbGetNextEntryCM(i,  &serv_id,  start_cost,  stream_cost) 

-calls  serv[i]->setld(serv_id) 

-calls  serv[i]->setResources(start_cost,  stream_cost) 

CostMtrx::dbGetNextEntryCM(int  inpl,  int*  servID,  int*  costl,  int*  cost2) 

_ //FileAccess  (ODBC) 

FILE  case 

(input  needed  for  keeping  track  of  last  file  position)  (FILE7.Z)  “CM***.dat” 

DB  case 

(input  needed  for  keeping  track  of  last  record) 

-selects  next  record  recX  in  structure  (DB10)  Cost_Matrix 
-sets  *  servID  =  recXfAl  0. Service] 

-sets  cost! [R_CPU]  =  recX[A10.CPU_Start_Cost] 

-sets  cost2[R_CPU]  =  recXfAl 0. CPU _Str earn _Cost] 

-sets  costl [R_MEMORY]  =  recX[A10.memory_Start_Cost] 

-sets  cost 2 [R_MEMORY]  =  recXfAl 0. memory _Str earn _Cost] 

-sets  costl [RJ3ANDWIDTH]  =  recXfAl 0. bandwidth _Start_Cost] 

-sets  cost2[R_BANDWIDTH]  =  recXfAl 0.  bandwidth  Str earn  Cost] 

NOTE:  In  current  version  this  function  accesses  elements  of  array  dbCM/7/7/7 
Service 

Service:: Service  //definition  of  entity 

{//MEMBERS 

int  id; 

Resource  resourceCost  [3]; 

//FUNCTIONS 

setld(int  input); 

setResources(int  *  costl,  int  *cost2); 

} 

Service:  :setld(int  input) 

-sets  id  to  input 
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Service:  :setResources(int  *costl,  int  *cost2) 

-for  i  =  R  CPU  to  R_BAND WIDTH 

-calls  resourceCost[i].setStartupFunction(costl[i]) 
-calls  resourceCost[i].setStreamFunction(cost2[i]) 


Resource 

&s/j:7LysVji?/A>-iGiyj ws/jy/*  '//?/.:.'/>  /jV/*.  vys/sm xiry^v.-ysvs v+r/s vy?/jLYs:vsw..:v: x: :csysr/<-\ yxvtr/yr/A  yys/jc/rv^.  Xut:z  :■>: /wr/sr/s y/r-y.'r/zy^  f 

Resource:  :Resource  //definition  of  entity 

{//MEMBERS 

int  startupFunction; 

float  startupCost; 

int  streamFunction; 

float  streamCost; 

//FUNCTIONS 

setStartupF  unction(input) ; 
setStreamFunction(input) ; 

} 

Resource::setStartupFunction(input) 

-sets  startupFunction  to  input 


Resource::setStreamFunction(input) 

-sets  streamFunction  to  input 


F.  FUTURE  REFINEMENTS 

The  application  should  not  necessarily  be  restrained  into  having  only  one  task’s  info 
cached  into  program’s  memory.  Info  for  a  predefined  maximum  number  of  tasks 
(MAX_SIZE)  could  be  kept  in  program’s  memory.  This  would: 

>  reduce  the  amount  of  “interaction”  with  the  storage  structures  (files  or  data  base) 

>  enable  a  form  of  fast  “switching”  between  tasks  (which  could  be  used  later  for 
satisfying  “multiple”  requests) 

A  track  of  usage  statistics  can  be  kept,  so  info  for  frequently  used  tasks  is  maintained  in 
memory.  When  there’s  a  request  for  a  task  not  present  in  memory,  and  maximum  number 
of  tasks  in  memory  is  already  reached,  the  least  used  task  could  be  deleted,  to  make  space 
for  loading  the  new  task’s  info. 

MAX_SIZE  can  be  decided  after  examining  the  average  size  of  a  task’s  info  and  the 
memory  available  for  program  operation. 

This  concept  is  illustrated  below  with  the  CSecurityCostsDoc  using  the  array 
Task*  applicationTask[MAX_SIZE] 

and  integer  member  nrTasks,  along  with  the  general  functions 
setupCurrentTaskQ 
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checklnListO 

leastUsedTaskQ 

and  the  Task  entity  having  additionally 
a  usage  member  and 
an  increaseUsageQ  member  function 

CSecurityCostsDoc::  CSecurityCostsDoc  //definition  of  entity 

{//MEMBERS 

Task*  applicationTask[MAX_SIZE];  //instead  of  one  task 

int  nrTasks;  //additional  member 


int  curTaskID;  //a  TASK  constant 
int  curModelD;  //a  NETWORK_MODE  constant 
int  curChoicelD;  //a  SECURITY_CHOICE  constant 
Task*  curTask; 

//ModeServiceMtrx*  curMSM; 

//TaskReqV  ector*  curTRV ; 

ModeChoiceMtrx*  curMCM; 

ChoiceVariableMtrx*  curCVM; 

TaskVariableVector*  curTVV; 

CostMtrx*  curCM; 

float  comp  Variable  [20]; 

//FUNCTIONS 

OnUserTask(); 

OnAdministratorNetworkMode(); 

OnU  serSecurityLevel() ; 

OnUserProcessCosts(); 

OnAdministratorSetupTask() 

selectTaskIDO; 

selectModeID(); 

selectChoiceID(); 

selectCurrentMatrices  V  ectors() ; 

costFormulaO(); 

costFormulal(); 

costFormula21(); 

costDispatcher(int  formula,  float*  result); 

plugValues(); 

nullComp  VariableArrayO ; 

calculateCosts(); 

} 

CSecurityCostsDoc::OnUserTask0 

-calls  selectTaskIDO 

-calls  setupCurrentTaskQ  //different  function  call 
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•calls  selectCurrentMatrices  Vectors  () 


CSecurityCostsDoc::setupCurrentTask() 

-defines  local  variable 
intk 

-if  selected  task  is  not  the  previous  current  task  (if  curTask->id  <>  curTaskID) 

-if  selected  task  does  not  exist  in  applicationTask[]  (if ! checklnList (curTaskID,  &k)) 
-if  task  list  is  full  (if  nrTasks>  =  MAXJSIZE  ) 

-calls  leastUsedTaskQ  and  sets  k  to  its  return  value 
-calls  delete  applicationTask[k] 

-decreases  nrTasks  =  nrTasks  - 1 
else 

-sets  k  =  nrTasks 

-creates  dynamically  applicationTask[k]  =  new  Task 

-increases  nrTasks  =  nrTasks+1 

-calls  applicationTask[k]->initialize(curTaskID) 

-sets  curTask  =  applicationTaskfk ] 

-calls  curTask->increaseUsage() 

CSecurityCostsDoc::checkInList(int  inp,  int*  index) 

-searches  elements  of  applicationTask[],  for  a  task  with  applicationTask[]->id  equal  to 
inp. 

If  it  finds  it,  it  puts  the  element  position  in  the  array  in  *index  and  returns  TRUE, 
otherwise  it  returns  FALSE. 

(  bool  result  =  FALSE; 
for  i—0  to  nrTasks 

if  applicationTask[i]->id  ==  id 
*index  =  i 
result  =  TRUE 
break 
return  result 

) _ 

CSecurityCostsDoc: :  leastUsedT  askQ _ 

-finds  and  returns  the  position  in  the  applicationTask[]  of  the  task  less  used  (that  is  of  the 
task  with  the  minimum  usage  member) 

(int  leastlndex  =  0 
for  i-1  to  (nrTasks-1) 

if  applicationTask[i]-> usage  <  applicationTask[leastIndex]-> usage 
leastlndex  =  i 
return  leastlndex 

) _ 

Task::Task  //definition  of  entity 

{//MEMBERS 

int  id; 
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int 

int 

long  int 

ModeServiceMtrx 

ModeChoiceMtrx 

CostMtrx* 

//FUNCTIONS 


nrComponents; 

nrServices; 

usage;  //additional  member 

taskMSM; 

taskMCM; 

taskCM; 


Task(int  inpl,  int  inp2,  int  inp3); 
initialize(int  inpl); 
setld(int  input); 
setMode(int  input); 
setChoice(int  input); 
setMatrices(); 

setModeServiceMatrix(int  input); 
setModeChoiceMatrix(int  input); 
setCostMatrix(int  input); 
increaseUsage(); 
calculateCosts(); 

dbGetEntryTask(int  input,  int  *parl,  int  *par2,  int  *par3); 
dbGetSpecificCM(int  input,  *par); 
dbGetNrEntriesCM(input,  *par); 


} 

Task::TaskO  //One  of  the  constructors 

-sets  usage=0 


Task: :  increaseUsageO 

-sets  usage =  us  age +1 


G.  ARRAYS 

As  previously  mentioned,  in  current  version  of  SecurityCosts  application  we  are  using 
arrays  to  store  the  costing  information  for  each  task. 

The  set  of  arrays  used  is  described  below: 

>  int  dbTask[MAX_TASK][5] 

1  st  dimension 

size:  number  of  defined  tasks 

description:  id  of  task  (incremental  index) 

2nd  dimension 
size:  5 

description:  []  [0]  number  of  Requirement  Components  (=  number  of  Component 

Variables)  of  Task 
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[][1]  number  of  Services  of  Task 
[]  [2]  id  of  MSM 
[]  [3]  id  of  MCM 
[]  [4]  id  of  CM 


>  int  dbMSMtoTRV[MAX_TASK]  [3] 

1  st  dimension 

size:  number  of  defined  tasks  (number  of  MSMs) 

description:  id  of  MSM  (incremental  index) 

2nd  dimension 
size:  3 

description:  [][0]  id  of  normal  TRV 
[]  [  1  ]  id  of  impacted  TRV 
[][2]  id  of  emergency  TRV 


>  float  dbTRV[MAX_TASK*  3  ]  [MAX_REQ_COMP]  [4] 


1  st  dimension 
size: 

description: 
2nd  dimension 
size: 

description: 
3rd  dimension 
size: 

description: 


number  of  possible  TRVs  (number  of  MSMs  *  number  of  Modes) 
id  of  TRV  (incremental  index) 


number  of  Requirement  Components  of  Task  with  max  nr  of  Requirement 
Components  (i.e.  max  of  dbTask[][0]  column) 
incremental  index  of  Task's  Requirement  Components 

4 

[][][0]  id  of  Requirement  Component 

[][][!]  id  of  Component  Variable  in  Requirement  Component 

[][][2]  minimum  acceptable  range  value 

[][][3]  maximum  acceptable  range  value 


>  int  dbMCMtoCVM[MAX_TASK]  [3] 

1  st  dimension 

size:  number  of  defined  tasks  (number  of  MCMs) 

description:  id  of  MCM  (incremental  index) 

2nd  dimension 
size:  3 

description:  [][0]  id  of  normal  CVM 
[]  [  1  ]  id  of  impacted  CVM 
[]  [2]  id  of  emergency  CVM 


>  int  dbC VMtoT VV [M AX_T ASK*  3  ]  [3  ] 

1  st  dimension 

size:  number  of  possible  CVMs  (number  of  MCMs  *  number  of  Modes) 

description:  id  of  CVM  (incremental  index) 

2nd  dimension 
size:  3 
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description:  [][0]  idoflowTVV 

[]  [  1  ]  id  of  medium  TV V 
[]  [2]  id  of  impacted  TVV 


>  float  dbT V V [MAX_T ASK*  3  *  3 ]  [M AX_REQ_COMP]  [3 ] 

1st  dimension 

size:  number  of  possible  TVVs  (nr  of  MCMs  *  nr  of  Modes  *  nr  of  Choices) 

description:  id  of  TVV  (incremental  index) 

2nd  dimension 

size:  number  of  Requirement  Components  of  Task  with  max  nr  of  Requirement 

Components  (i.e.  max  of  dbTask[][0]  column) 
description:  incremental  index  of  Task's  Variable  Components 
3rd  dimension 
size:  3 

description:  [][][0]  id  of  Component  Variable 

[]  []  [  1  ]  minimum  user  accepted  value 
[][][2]  maximum  user  accepted  value 


>  int  dbCM[MAX_TASK][MAX_SERV][7] 


1st  dimension 
size: 

description: 
2nd  dimension 
size: 

description: 
3rd  dimension 
size: 

description: 


number  of  defined  tasks  (number  of  CMs) 
id  of  CM  (incremental  index) 

number  of  Services  of  Task  with  max  number  of  Services 
(i.e.  max  of  dbTask[][l]  column) 
incremental  index  of  Task's  Services 


7 

[][][0]  id  of  Service 

[][][1]  id  °f  CPU  start-up  CostFormula 

[][][2]  id  of  CPU  streaming  CostFormula 

[][][3]  id  of  MEMORY  start-up  CostFormula 

[][][4]  id  of  MEMORY  streaming  CostFormula 

[]  []  [5  ]  id  of  BANDWIDTH  start-up  CostF ormula 

[][]  [6]  id  of  BANDWIDTH  streaming  CostFormula 


H.  DATA  BASE  STRUCTURES 


(DBl)  Task 

Structure  containing  for  each  task  corresponding  indexes  to  Mode-Service,  Mode-Choice 
and  Cost  Matrices. 

Number  of  entries  equals  number  of  defined  tasks. 
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Field 

Description 

Example 

ID 

integer 

a  TASK  constant  -  indicates  task’s  id 

0  (T_FTP) 

Mode-Service 

integer 

indicates  id  of  corresponding  Mode-Service 
matrix 

Mode-Choice 

integer 

indicates  id  of  corresponding  Mode-Choice 
matrix 

Cost 

integer 

indicates  id  of  corresponding  Cost  matrix 

NrComponents 

integer 

indicates  number  of  requirement 
components  (=number  of  component 
variables)  of  task 

NrServices 

integer 

indicates  number  of  security  services 
invoked  by  task 

NOTE:  for  a  different  costing  algorithm  another  field  could  be  added,  for  an  alternative 
cost  matrix. 

(DB2)  MSM_to_TRV 

(MODE-SERVICE  MATRIX  to  TASK  REQUIREMENT  VECTOR) 

Structure  containing  for  each  Mode-Service  Matrix  indexes  to  Task  Requirement 
Vectors  according  to  network  mode. 

Number  of  entries  equals  number  of  defined  tasks. 


Field 

Description 

Example 

ID 

integer 

indicates  Mode-Service  Matrix’s  id 

Normal_TRV 

integer 

indicates  id  of  Task  Requirement  Vector  for 
normal  mode 

Impacted_TRV 

integer 

indicates  id  of  Task  Requirement  Vector  for 
impacted  mode 

Emergency_TRV 

integer 

indicates  id  of  Task  Requirement  Vector  for 
emergency  mode 

(DB3)  Requirement_Components 

Structure  containing  all  possible  requirement  components,  related  to  their  containing 
Task  Requirement  Vector. 
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nrTRV 

Number  of  entries  equals  to  ^nrCompj  ,  where 

/=] 

nrTRV  =  number  of  all  possible  Task  Requirement  Vectors 
=  number_of_T asks  *  number_of  modes 

nrCompi  =  number  of  requirement  components  of  TRV  i  (which  is  a  matter  of  definition) 

NOTE:  If  the  same  component  belongs  to  a  different  task,  there  will  be  a  separate  entry 
for  it. 


Field 

Description 

Example 

ID 

integer 

indicates  Requirement 
Component’s  id 

TRV 

integer 

indicates  id  of  Task  Requirement 
Vector  to  which  component 
belongs 

VariableLHS 

integer 

a  COMPONENTS ARIABLE 
constant  -  indicates  variable 
clause  of  component 

1  (C  V_KE  Y_LEN  GTH) 

MinRangeValue 

float 
a  number 

.6 

Max_Range_V  alue 

float 
a  number 

.7 

NOTE:  Additional  fields  e.g.  for  instantiated  values  can  be  included 

(DB4)  Task_Requirement_Vector 

In  order  to  create  a  specific  Task  Requirement  Vector  X: 

SELECT  in  REQUIREMENT_COMPONENTS  (TRV  =  X) 
PROJECT  (all  fields  but  TRV) 


Field 

Description 

Example 

ID 

integer 

indicates  Requirement 
Component’s  id 

VariableJLHS 

integer 

a  COMPONENT_V  ARIABLE 
constant  -  indicates  variable 
clause  of  component 

1  (CV_KEY_LENGTH) 

float 
a  number 

.6 

Max_Range_V  alue 

float 
a  number 

.7 
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(DB5)  MCM_to_CVM 

(MODE-CHOICE  MATRIX  to  CHOICE  VARIABLE  MATRIX) 

Structure  containing  for  each  Mode-Choice  Matrix  indexes  to  Choice  Variable  Matrixes 
according  to  network  mode. 

Number  of  entries  equals  number  of  defined  tasks. 


Field 

Description 

Example 

ID 

integer 

indicates  Mode-Choice  Matrix’s  id 

NormalCVM 

integer 

indicates  id  of  Choice- Variable  Matrix 
for  normal  mode 

Impacted_CVM 

integer 

indicates  id  of  Choice-Variable  Matrix 
for  impacted  mode 

Emergency_CVM 

integer 

indicates  id  of  Choice-Variable  Matrix 
for  emergency  mode 

(DB6)  CVM  _to_TVV 

(CHOICE-VARIABLE  MATRIX  to  TASK  VARIABLE  VECTOR) 

Structure  containing  for  each  Choice  Variable  Matrix  indexes  to  Task  Variable  Vectors 
according  to  security  level  choice. 

Number  of  entries  equals  number_of_tasks  *  number_of_modes. 


Field 

Description 

Example 

ID 

integer 

indicates  Choice- Variable  Matrix’s  id 

Low_TVV 

integer 

indicates  id  of  Task  Variable  Vector  for  low  level 
security  choice 

Medium_TVV 

integer 

indicates  id  of  Task  Variable  Vector  for  medium 
level  security  choice 

High_TVV 

integer 

indicates  id  of  Task  Variable  Vector  for  high 
level  security  choice 

(DB7)  Variable_Values 

Structure  containing  all  possible  variable  values,  related  to  their  containing  Task  Variable 
Vector. 

nr  nr 

Number  of  entries  equals  to  ^nrComp,  ,  where 

i=i 

nrTVV  =  number  of  all  possible  Task  Variable  Vectors 

=  number_of_T asks  *  number_of  jmodes  *  number_of_security_choices 
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nrCompi  =  number  of  requirement  components  of  corresponding  Task’s  TRV  i  (which  is 
a  matter  of  definition) 


NOTE:  If  the  same  variable  with  the  same  value  belongs  to  a  different  Task  Variable 
Vector,  there  will  be  a  separate  entry  for  it. 


Field 

Description 

Example 

TVV 

integer 

indicates  id  of  Task  Variable  Vector 
to  which  variable  belongs 

Variable_LHS 

integer 

a  COMPONENT_VARIABLE 
constant  -  indicates  variable  clause 
of  component 

1  (CV_KEY_LENGTH) 

Min_V  alue_RHS 

float 

number  indicating  minimum  of 
acceptable  value  range 

.6 

Max_V  alue_RHS 

float 

number  indicating  maximum  of 
acceptable  value  range 

.6 

(DB8)  Task_Variable_Vector 
In  order  to  create  a  specific  Task  Variable  Vector  X: 
SELECT  in  VARIABLE_VALUES  (TVV  =  X) 
PROJECT  (all  fields  but  TVV) 


Field 

Description 

Example 

Variable JLHS 

integer 

a  COMPONENTVARIABLE 
constant  -  indicates  variable  clause 
of  component 

1  (CV_KEY_LENGTH) 

Min_Value_RHS 

float 

number  indicating  minimum  of 
acceptable  value  range 

.6 

Max_V  alue_RHS 

float 

number  indicating  maximum  of 
acceptable  value  range 

.6 

(DB9)  CM_to_Service_Costs 

(COST  MATRIX  to  SERVICE  RESOURCE  COSTS): 

Structure  containing  Service  Costs  related  to  their  containing  Cost  Matrix. 

nrTasks 

Number  of  entries  equals  ^  nrServiceS; ,  where 

/=! 

nrTasks  =  number_of_Tasks 

nrServiceSj  =  number  of  services  of  Task  i  (which  is  a  matter  of  definition) 
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NOTE:  If  the  same  service  belongs  to  a  different  task,  there  will  be  a  separate  entry  for  it. 

Field  Description  Example 

Service  integer  3  (S_INTEGRITY_NW) 

a  SERVICE  constant  -  indicates 

id  of  service  _ 

CM  integer 

indicates  id  of  Cost  Matrix  to 

which  service  belongs.  _ 

CPU_Start_Cost  integer 

indicates  id  of  function  used  to 
calculate  start  cost  for  CPU. 

CPU_Stream_Cost  integer 

indicates  id  of  function  used  to 

calculate  streaming  cost  for  CPU.  _ 

memory_Start_Cost  integer 

indicates  id  of  function  used  to 

calculate  start  cost  for  memory.  _ 

memory_Stream_Cost  integer 

indicates  id  of  function  used  to 
calculate  streaming  cost  for 

memory.  _ 

bandwidth_Start_Cost  integer 

indicates  id  of  function  used  to 

calculate  start  cost  for  bandwidth.  _ 

bandwidth_Stream_Cost  integer 

indicates  id  of  function  used  to 
calculate  streaming  cost  for 

bandwidth.  _ 

(DB10)  Cost_Matrix 

In  order  to  create  a  specific  Cost  Matrix  X: 

SELECT  in  CM_to_SERVICE_COSTS  (CM  =  X) 

PROJECT  (all  fields  but  CM) 

Field  |  Description  I  'Emmple 

Service  integer  3  (S_INTEGRITY_ES) 

a  SERVICE  constant  -  indicates 

id  of  service  _ 

CPU_Start_Cost  integer 

indicates  id  of  function  used  to 

calculate  start  cost  for  CPU.  _ 

CPU_Stream_Cost  integer 

indicates  id  of  function  used  to 

calculate  streaming  cost  for  CPU. _ 

memory_Start_Cost  integer _ 
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indicates  id  of  function  used  to 
calculate  start  cost  for  memory. 


memory_Stream_Cost 

integer 

indicates  id  of  function  used  to 
calculate  streaming  cost  for 
memory. 

bandwidth_Start_Cost 

integer 

indicates  id  of  function  used  to 
calculate  start  cost  for  bandwidth. 

bandwidthStreamCost 

integer 

indicates  id  of  function  used  to 
calculate  streaming  cost  for 
bandwidth. 

Low  Level  Specification  of  QoSS  Costing  Demonstration  for  MSHN  0.3 


41 


INITIAL  DISTRIBUTION  LIST 


Defense  Technical  Information  Center 
8725  John  J.  Kingman  Rd.,  STE  0944 
Ft.  Belvoir,  VA  22060-6218 

Dudley  Knox  Library,  Code  013 
Naval  Postgraduate  School 
Monterey,  C A  93943-5100 

Research  Office,  Code  09 
Naval  Postgraduate  School 
Monterey,  CA  93943-5138 

Dr.  Cynthia  E.  Irvine 
Code  CS/Ic 

Department  of  Computer  Science 
Naval  Postgraduate  School 
Monterey,  CA  93943-5 118 


